I am trying to figure out how to best implement this for my system…and get my head out of the RDBMS space for now…
A part of my current DB has three tables: Show, ShowEntry, and Entry. Basically ShowEntry is a many-to-many joining table between Show and Entry. In my RDBMS thinking it’s quite logical since any changes to Show details can be done in one place, and the same with Entry.
What’s the best way to reflect this in a document-based storage? I’m sure there is no one way of doing this but I can’t help but think if document-based storage is appropriate for this case at all.
FYI, I am currently considering implementing RavenDB. While discussions on general NoSQL design will be good a more RavenDB focused one will be fantastic!
Thanks,
D.
When modelling a many-to-many relationship in a document database, you usually store a collection of foreign keys in just one of the documents. The document you choose largely depends on the direction you intend to traverse the relationship. Traversing it one way is trivial, traversing it the other way requires an index.
Take the shopping basket example. It’s more important to know exactly which items are in a particular basket than which baskets contain a particular item. Since we’re usually following the relationship in the basket-to-item direction, it makes more sense to store item IDs in a basket than it does to store basket IDs in an item.
You can still traverse the relationship in the opposite direction (e.g. find baskets containing a particular item) by using an index, but the index will be updated in the background so it won’t always be 100% accurate. (You can wait for the index to become accurate with
WaitForNonStaleResults, but that delay will show in your UI.)If you require immediate 100% accuracy in both directions, you can store foreign keys in both documents, but your application will have to update two documents whenever a relationship is created or destroyed.