3 ms·

I've seen several complex businesses with incredibly complex processes and systems that were entirely based on relational databases, and changes were always fas

by ratww 5y ago

I've seen several complex businesses with incredibly complex processes and systems that were entirely based on relational databases, and changes were always fast in the database side. The database itself is agile and it is easy to modify and migrate. The problem always lies on excessive abstractions and patterns on the backend side. Which really isn't solved anywhere by any strategy other than keeping things damn simple. Your descriptions of "impedance mismatch when converting relational models to business models" and "automating mappers that leads to a hardened and immovable design" are a precise example of that: OOP patterns muddying the development process and causing problems in unrelated parts of the system (in this case the database). Of course, keeping things simple and programming in a way that fits the relational model is incredibly difficult for developers that have been trained to believe that complexity is the answer to all problems future and past. So the resort for those people is to keep pestering management to throw the baby (relational databases) with the bathwater (relational mappers and other related OOP patterns).

ChicagoDave 5y ago
I used to think this way as well. Then I rebuilt the performance management system at Accenture using domain centric micro services and a document database. Not only were we able to build faster (schemaless is so much easier on change management), but also offers the ability to add features at a frighteningly fast pace. No RDBMS-centric project I have ever worked on comes close to the efficiencies of what we did on that project and on projects since using the same paradigms. And when people needed the transactional data in a relational model, we streamed events and that was read only in some other tool and the core system didn't need to know about any of that. Been down this road. Saw a fork in 2015 and haven't looked back.
- HelloNurse 5y ago
  > domain centric micro services and a document database It sounds like you put ORM hell behind you by getting rid more of objects than of databases. > Not only were we able to build faster (schemaless is so much easier on change management), but also offers the ability to add features at a frighteningly fast pace What kind of change management? Frightening clients with API changes? Eluding code reviews and formal release processes?

by ratww 5y ago

ChicagoDave 5y ago

I used to think this way as well. Then I rebuilt the performance management system at Accenture using domain centric micro services and a document database. Not only were we able to build faster (schemaless is so much easier on change management), but also offers the ability to add features at a frighteningly fast pace. No RDBMS-centric project I have ever worked on comes close to the efficiencies of what we did on that project and on projects since using the same paradigms. And when people needed the transactional data in a relational model, we streamed events and that was read only in some other tool and the core system didn't need to know about any of that. Been down this road. Saw a fork in 2015 and haven't looked back.

HelloNurse 5y ago
> domain centric micro services and a document database It sounds like you put ORM hell behind you by getting rid more of objects than of databases. > Not only were we able to build faster (schemaless is so much easier on change management), but also offers the ability to add features at a frighteningly fast pace What kind of change management? Frightening clients with API changes? Eluding code reviews and formal release processes?