3 ms·
I was just going for a run and thinking about the whole NoSQL thing...can someone clear something up for me? Do document stores still associate records with one
by ryanwaggoner 16y ago
I was just going for a run and thinking about the whole NoSQL thing...can someone clear something up for me? Do document stores still associate records with one another via foreign keys (but with multiple queries rather than joins), or do they store the same info repeated across multiple records?
For example, let's say you have a blog that's using a key-value store, and posts can have many tags. Does each post document have the tags in the record itself, or does the post document have the ids for the tag records, which the system would retrieve in a subsequent query? Or am I missing it completely? Links to any helpful articles on transitioning from a relational database to a document store would be awesome.
- bkudria 16y agoWell, you can structure it both ways. You can specify IDs, and perform extra queries, or you can "inline" the data, duplicating it across the hierarchy, but saving yourself extra queries. It all depends on your use case.
- ryanwaggoner 16y agoThanks for the info. Can you elaborate a bit? I guess I'm asking more which is the "right" way to do it most of the time. You can just json all your data into a giant mysql table, but that's usually not the preferred way to use a relational database. So what's the preferred way to use a document store?
- michaelfairley 16y agoThe preferred way is to place a tags array in the post document, and also create an index across this array (allowing efficient lookup by tag). There's actually a specific documentation page for this usage: http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mongo http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mong...
- ryanwaggoner 16y agoCool...thank you very much!
- bl4k 16y agothe shortcut to think about it when designing a doc-based schema is as follows: what would be a one-to-one or one-to-many relationship in a traditional RDBMS would be embedded data in the document in a doc based store. What would be a many-to-many relationship would be stored as a separate document and referenced with a foreign key.
- m_eiman 16y agoduplicating it across the hierarchy Do the data stores do de-duplication internally to make this less expensive storage-wise?
- andrewtj 16y agoI've found the resources the folks at Basho (makers of Riak) have put together on their wiki and blog quite useful. The following would be a good starting point: http://blog.basho.com/2010/03/19/schema-design-in-riak---introduction/ http://blog.basho.com/2010/03/19/schema-design-in-riak---int... http://blog.basho.com/2010/03/25/schema-design-in-riak---relationships/ http://blog.basho.com/2010/03/25/schema-design-in-riak---rel... http://wiki.basho.com/ http://wiki.basho.com/ http://blog.basho.com/ http://blog.basho.com/
- epochwolf 16y agoHere's an example schema. Users { _id:string //doubles for user's name password: { hash:string salt:string } website:string bio:string following:array of { username:string articles:boolean comments:boolean } } Articles { _id:ObjectID //auto id title:string contents:string owner:string //references Users tags:array of strings //no reference, tags are either unfiltered or selected from a global tag list. } Comments { _id:ObjectID //auto id contents:string owner:string //references Users root:ObjectID //references Articles instead of Comments parents:array of ObjectIDs //using materialized path for threading of comments } Config { _id:string value:? //untyped can store anything in json format } Note: The references are defined entirely in software, the database is not aware of them.