There is no such thing as a schemaless database. Just databases that dont support validating data. Which means your code has to do it. It also means that the schema is your whole code base. And of course you are never sure of all changes to the schema were applied to the whole database. So you put null checks everywhere.
Exactly, the schema constraints just move to your application code, where there is a far greater chance of making an error. Plus you also have to duplicate the constraint logic in every new service you write.
Thank you for chiming in! I wish there was a single way to settle this. :)
I don't have time to write an in depth article addressing how I'm using MongoDB, but I have written a previous article discussing the architectural principle of domain decoupling. This article is actually more a case against domain driven design.
I produced a video about the dangers of coupling to the design here:
I have also produced a video about the solution I developed which implements domain decoupling here:
In Gravity the data structures are defined by runtime configurations that are also stored in MongoDB. This means that users can define new data structures at runtime along with detailed business process rules without a line of code.
The project started with JackRabbit JCR as the data store, but recently moved to MongoDB. Both JackRabbit and MongoDB opened the door do writing data decoupled applications. This application automatically handles issues like security and ownership. And now with the help of Mongo Aggregations and lookups we are able to provide similar functionality to SQL queries.
Thank you for the detailed answer! I will spend some time going through these links and what you wrote, and come back to comment.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.