5 ms·
> But relational databases are an architectural anti-pattern. This is such an inflammatory and ignorant statement that I don't really have any other answer oth
by ratww 5y ago
> But relational databases are an architectural anti-pattern.
This is such an inflammatory and ignorant statement that I don't really have any other answer other than to call it pure bullshit. Relational Databases are probably one of the few popular areas of our profession that are not only backed by formalisms and research that tell us to do it correctly, it is also proven to work in practice: it is the de facto backbone of most financial, commercial, government systems and, heck, even military, but also even of modern FAANG-style big tech.
Sure, they're boring. And it takes time to learn. And normalisation might has its costs but we can know them all upfront, and we know where and how to break them. The (currently trendy) horizontal scalability is indeed non-trivial with them, but vertical and horizontal-via-sharding are easier than most ad-hoc solutions. But the boredom pays off in guarantees, and to learn you have 50 years of mature material to rely on.
(This is not to say that non-relational databases are useless. Both have its uses, but they're both only really useful if you properly understand them)
Complex enterprise systems are complex for reasons beyond the technology. Often due to processes and bureaucracies. Those complexities often end up turning into "essential complexity" in systems, and Domain Driven Design is not able to reduce such essential complexity, and nothing can.
Nor is Domain Driven Design incompatible with relational databases, especially the tactical part, which is often the major selling point of DDD. It is entirely possible to model domains within databases, and is entirely common.
Also, DDD is not a guarantee of success. If anything, it has not proven itself nowhere near as much relational databases have. As much as the original idea of DDD is good (again, especially the tactical part), it I see it often become rationalisation for the same old architecture astronautics that cause excessive incidental complexity. For people wanting architectural complexity, I can completely understand the distaste for something simple like "keeping it in the DB". It completely negates all the fancy technical patterns prized by developers. This is not to discount the original idea and techniques of DDD: merely saying that the excuse "relational databases can be bad if not well done" applies as often, if not more, to the practice of DDD.
- HelloNurse 5y agoRelational databases work so well that they are also highly effective when used badly. So it's easy to succumb to temptation and take the easy path (I don't want to add three tables to keep it normalized... let's allow this column to be null, the applications can check... another field for the second phone number, we'll see about the third one... make your queries non-isolated or we could have a deadlock...) with apparently good results, and then when technical debt comes home the architecture amateurs can blame the tools instead of themselves.
- ChicagoDave 5y agoIt'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 agoI'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 agoI 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.
- ChicagoDave 5y agoAfter 30 years of architecture based on RDBMS, it's my opinion that _starting_ with a relational model ends up hiding and obfuscating business functionality at the expense of relational paradigms. I didn't say relational databases are bad. I said it was an anti-pattern. In my mind, relational databases should be mostly used in data warehouses, reporting, and analytical systems. Transactional systems are better suited to document databases and CQRS.