Recently I've been wanting to experiment with NoSQL databases, especially document store ones. After reading, I still don't understand how one might model information that is contained in a relational SQL database (i.e with tables and records) in terms of documents.For example, a music database might have a table for Artists, Albums and Issues; an Album can have one or more Artists, and an Album can one or more Issues. This is a relatively simple example.From what I understand of the uses of documents, there will be a document for every Album, and inside that document, the artists key will contain the information on each Artist, and the issues key will contain the information on each Issue of that Album.Doesn't this lead to a lot of data duplication? Each album by an artist will need to contain all the information about its artist(s). On the other hand, if we have a document for every Artist, and an album has five artists and ten issues, then the album information is replicated five times within the document for each Artist and the issues information is replicated ten times within the key for each Album.I believe I'm not thinking about the storage correctly, as this seems like a very silly way to organise a database. Either NoSQL isn't suited for this kind of storage (and I should stick to SQL), or this storage can be implemented in a better way (and I'm too stupid to see how).Would another kind (i.e not document storage) of NoSQL database be better suited? How might one organise my example schema in a NoSQL database, with minimal data duplication? Would data duplication be somehow better?Thank you.
How can one think of a relational schema in terms of storing it in a NoSQL database?
database;nosql;relational database;dry;hierarchy