In terms of database usage, the last decade has been the age of ORM, with hundreds competing to save our object schedules in plain old-fashioned RMDBS. Now, we seem to be witnessing the onset of the age of document-oriented databases. These databases are highly optimized for documents without a schema but are also very attractive for their ability to scale and query a cluster in parallel.
Documented databases also have several advantages over RDBMS for storing data models in object-oriented projects. Since tables do not contain schemas, you can store objects belonging to different classes in the inheritance hierarchy side by side. In addition, as the domain model changes, if the code can handle returning objects from the old version of the domain classes, you can avoid migrating the entire database with each change.
On the other hand, the advantages of using document-centric databases mainly arise when storing deeper documents. In object-oriented terms, classes consisting of other classes, such as a blog post and its comments. In most examples of this, I can come up with, although, for example, on a blog, access to reading will depend on the fine for writing the entire blog “document” every time a new comment is added.
It seems to me that document-oriented databases can bring significant benefits to object-oriented systems if you take special care to organize objects in deep graphs that are optimized for how data will be read and written, but that means knowledge front. In the real world, we often do not know until we actually have a real implementation that we can profile.
So is a relational or document-oriented database one of the swings and carousels? I'm interested in the opinions and advice of people, in particular, if someone created important applications in a document-oriented database.
source
share