I am thinking about starting my first CouchDB project and coming from an ORM background I am concerned how to create my documents that may be difficult to maintain.
For example, if I have the following model :
A *--->(1)B
which means for every A object there is a B object and there are many instances of A that can share a B object. In this case there are pointers/foreign key in A to B.
I could create a document that contains all the A data and the B data. However, the issue I have is if at a later stage (after 10000s of documents are created), I may need to change some data which means I have to update all my documents.
In an ORM/normalised database world I would simple update B and all my references are now up to database.
How do I handle this in CouchDB or is the NoSQL approach not suited for these types of situations?
JD
First of all, it is important to understand that NoSQL doesn't follow the same principles as Relational Databases such as fixed schemas, normalization, support for expressive queries like SQL.
Denormalization is the “community approved standard” to deal with related data in NoSQL systems.
Normalizing your data like you would with a relational database is usually not a good idea in MongoDB. Normalization in relational databases is only feasible under the premise that JOINs between tables are relatively cheap.
Using MongoDB removes the need to normalize data to accommodate the database. Instead, you can store the same objects you are using in the code.
The general answer to this question: There is no general answer to this question.
The point is that in NoSQL, the data structure is not dictated by the data, but rather by the queries the data structure must support. So, rather than using the same pattern for each and every instance of a 1:N or M:N association problem, the NoSQL way is to use different patterns depending on your specific needs. These could be, for instance:
Generally, my feeling is that beginners tend to 'over-embed', but I can speak for MongoDB only. Embedding is a powerful feature, but embedded objects are not 'first-class citizens', so it shouldn't be used as a replacement for every 1:n relation. Only for some :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With