Quote:
Originally Posted by parityboy 
lol guys, thanks for the replies (and the in-thread convo, lol). I discounted relational for performance reasons, simply because the data I'm looking to store maps better to document and K/V structures. After looking at the fragment I posted, I'm beginning to think K/V is the way to go, but I know little about them apart from the basic concept.
What's your experience with K/V databases as a developer? Are they easy to use? What do you use to query them - is there a common query language?
lol guys, thanks for the replies (and the in-thread convo, lol). I discounted relational for performance reasons, simply because the data I'm looking to store maps better to document and K/V structures. After looking at the fragment I posted, I'm beginning to think K/V is the way to go, but I know little about them apart from the basic concept.
What's your experience with K/V databases as a developer? Are they easy to use? What do you use to query them - is there a common query language?
I've only ever written bespoke "in memory" K/V databases, so I can't really be much help. But you know the values you need each time (ie it's always going to have those 17 fields per record), the you could always create a multi-dimensional array and store in there. The memory requirements might be huge for some of the larger datasets - but you're going to run into that issue with whichever solution you opt for. So the only other work around would be to either discard surplus information (and then read that back from the net if/when requested), or to use a staggered load where only (for example) 50 records are loaded at a time.
