views:

257

answers:

2

i have been in the RDBMS world for many years now but wish to explore the whole nosql movement. so here's my first question:

is it bad practice to have the possibility of duplicate keys? for example, an address book keyed off of last name (most probably search item?) could have multiple entities. is it bad practice to use the last name then? is the key supposed to be the most "searchable" definition of the entity? are there any resources for "best practices" in this whole new world (for me)?

i'm intrigued by tokyo cabinet (and specifically the tc interface) but don't know how to iterate through different entities that have the same key (e.g. see above). i can only get the first entity. anyway, thanks in advance for the help

A: 

In a key-value store you cannot have duplicate keys, there's a single value behind a key. To have duplicate keys you can use the B+ Tree database in Tokyo Cabinet that has values ordered and allows duplicate (you can acces them by going to the first item with that key and iterating).

Not all problems are easily solved by a key-value store as you need the key to retrieve the item. Maybe something like MongoDB is more appropriate as allows more complex queries.

Mihai A
A: 

This depend on no-sql implementation. Cassandra, for example, allows range queries, so you could model data to do queries on last name, or with full name (starting with last name, then first name).

Beyond this, many simpler key-value stores would indeed require you to store a list structure (or such) for multi-valued entries. Whether this is feasible or not depends on expected number of "duplicates" -- with last name, number could be rather high I presume, so it does not sound like an ideal model for many cases.

StaxMan