I'm probably a bit late on this, but none of these points touched on a software engineer building a complex architecture for no reason. I have seen this so many, many times. Yes, they can handle point #1. They take all the tickets associated with it and solve them quickly because they built it and know all the connections. The implementation makes no attempt (or claim) at scalability so that's a moot point. For point #3, interestingly enough these are never about optimization of anything, but about abstraction over abstraction over abstraction. As for the graph DBs, those aren't allowed anyway by the company they work for (thank goodness) or they would find some way to incorporate them.<p>Yes, I'm being a bit glib, but over-engineering does not always mean there's some good intentions in there. It can just be really bad.
graph dbs are just easily traversable joins of all many-to-many tables. although they have way less tooling in most ecosystems to support them (e.g. REST API was tough to do), they are extremely powerful [realizing i should write a post]. so, i would only use the entities i was modeling were natural graphs: chemistry, supply chain, network.<p>neomodel is a fantastic python ORM for a neo4j: <a href="https://neomodel.readthedocs.io/en/latest/" rel="nofollow">https://neomodel.readthedocs.io/en/latest/</a>
Build it the stupid way first is short sighted imo but this might just be an exaggerated way of saying premature optimisation is wasteful.<p>Just putting it out there, but I think Knuth’s aphorism is being used and abused to the point that some folk believe system qualities are second to functional requirements when it’s not the case.