ORMs Are Backwards
So, I&#x27;ve seen this go back and forth so many times, and I&#x27;ve come to the conclusion that the two extremes are irreconcilable. Not because they&#x27;re incorrigible, but because they represent two very different ways of using a database.<p>For some, the database is not actually a database, per se, it&#x27;s just a place to persist state. Usually folks in this camp think in an object-oriented way. They haven&#x27;t read Codd&#x27;s paper, they don&#x27;t care about the relational algebra, they just want some way to take bags of properties and stick them somewhere that offers random access with good performance and is reasonably unlikely to not spontaneously erase data. If you&#x27;re in this camp, ORM works great, because there isn&#x27;t really much of an object&#x2F;relational impedance situation in the first place. The data store wasn&#x27;t structured in a way that creates one, there&#x27;s no need burn a bunch of effort on doing so, and dragging in the whole relational way of doing things is like dragging a wooden rowboat on a hike through the forest because you&#x27;d like to use it to go fishing on the off chance you find a nice pond.<p>Others see a lot of value in the relational model. They&#x27;re willing to put a bunch of time and effort into structuring the data and organizing the indexes in ways that will allow you to answer complex, possibly unanticipated questions quickly and efficiently. They, too, hate the syntax for recursive common table expressions, but are willing to hold their nose and use them anyway, for various reasons, but mostly because people think you&#x27;re really cool when you can spend 30 minutes and make something go 2-3 orders of mangnitude faster than it used to. They don&#x27;t think of the data in terms of bags of properties, they think of it in terms of tuples and relations and a calculus for rearranging them in interesting and useful ways. For them, there is potentially a <i>huge</i> problem with object&#x2F;relational impedance; the data&#x27;s organized in ways that just don&#x27;t fit cleanly into Beans.<p>The thing is, neither of these ways of using a database is wrong. Each has it strengths and weaknesses. The trick is figuring out which way fits your business needs. Well, that&#x27;s the easy trick. The hard trick comes when someone on your team doesn&#x27;t understand this, believes there is one universal solution that will work for everyone, and is hellbent on jamming the One Righteous and Holy Peg, which happens to be square, into a round hole.