In my own experience, deploying applications on traditional relational databases is a pain. Most of the applications I have worked on were applications for State government. The applications get heavily tied to the database, requiring the database to be populated to test the logic. The table structures are unnecessarily convoluted. These applications process client data (eligibility, certifications, enrollment) sometimes in the context of state data.
I have built solutions that allow me to collect data from running applications, and later inject data from these collected scenarios into the business logic for testing and debugging.
All of this to say that any objective analysis of these systems would reveal no need for a relational database. In fact, imposing the relational transaction model onto these applications is clearly detrimental to the development of these systems, the cost of these systems, the testability of these systems (though this isn't really the fault of the database technology itself), and the performance of these systems.
We should be processing the information through an application designed solely according to the needs of the application, and then selective pushing data to a data warehouse for reporting (which can certainly be a relational database).
It is almost like Ford claiming all your transportation needs require a truck, and forcing all supermarkets to accommodate driving trucks up and down the grocery aisles...
Nobody would say you don't need trucks. But the fact that trucks are sometimes needed isn't proof you should always use a truck.
I have built solutions that allow me to collect data from running applications, and later inject data from these collected scenarios into the business logic for testing and debugging.
All of this to say that any objective analysis of these systems would reveal no need for a relational database. In fact, imposing the relational transaction model onto these applications is clearly detrimental to the development of these systems, the cost of these systems, the testability of these systems (though this isn't really the fault of the database technology itself), and the performance of these systems.
We should be processing the information through an application designed solely according to the needs of the application, and then selective pushing data to a data warehouse for reporting (which can certainly be a relational database).
It is almost like Ford claiming all your transportation needs require a truck, and forcing all supermarkets to accommodate driving trucks up and down the grocery aisles...
Nobody would say you don't need trucks. But the fact that trucks are sometimes needed isn't proof you should always use a truck.