![]() Imagine trying to change a schema on the fly while there are users online. Dynamic changes to SQL can be time consuming and potentially dangerous. I've seen a similar application as the one I'm working on and the pipeline of SQL schema scripts and messing about is scary. It delivers a kind of flexibility and adaptability that allows us to do things which are essentially impossible to do with SQL databases. You can store arbitrary data easily and allow users to define what data they want to store at run time rather than design time. The door MongoDB opens is the ability to write applications that are not tightly coupled to the binary. If you are simply going to build applications like you did with SQL and expect it to be feature for feature identical you are missing the benefits. The who point of MongoDB is the flexibility. If you simply treat MongoDB as any other relational database and build applications tightly coupled with a schema it is like complaining that your trail bike doesn't go as fast as your Ferrari or carry as much as your pickup truck. However it became clear to me that using MongoDB directly would give me all the same features with far better performance. Later this technology adopted MongoDB under the covers. It actually used PostgereSQL under the covers, but it allowed huge flexibility that decoupled the code from schema. In 2013 I began working on a Automation Engine which used a data storage mechanism which was flexible. ![]() Where tight coupling between code and schema is acceptable. There are workloads where the data structures are mature and unchanging, where flexibility and adaptability isn't critically important. I was a dBase programmer back in the early ninties. I spent decades dealing with this kind of problem from even before SQL. Changing the data structure becomes almost impossible without management of both binary deployment and schema changes. You will build business rules into the domain objects. when you bind the data structure to the binary artifacts you cripple flexibility. The model is usually established by the SQL and object model, with a mapping using Hibernate or whatever other object relational mapper. In this statement there is the core weakness of orthodox software development, mainly that the foundation stone of our software is the model. The orthodox thinking is on clear display when Noah says "one of the most important parts of designing a system is fleshing out your data model". And to be frank some of the comments below indicate that using non SQL data storage is still considered heterodox. There was a time when the idea of using anything but a SQL database was heretical. Long time user of SQL of various varieties and PostgreSQL specifically.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |