3 ms·

It's not just about poorly designed relational models. It's also about impedance mismatch when converting relational models to business models. You end up autom

It's not just about poorly designed relational models. It's also about impedance mismatch when converting relational models to business models. You end up automating that using object-relation mappers and this leads to a hardened and immovable design. Eventually, the business will ask for a significant change and the tech staff will put forth their costly assessment for that change. Then the business has to decide to either rewrite the system or to pay for the tech debt or (worst case) hack the new features into the existing architecture. Many times, it all gets punted and the business lives with the complexity. I've seen this way too many times to back off of my assessment. Relational models do not, in the long term, enable an agile business model. It is an anti-pattern even if it takes years to reveal itself as such.

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?

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?