Oops, You Wrote a Database
The same can be said about ORMs...<p>- You start of thinking, my problem is simple&#x2F;unique so I don&#x27;t need an ORM<p>- You design your database schema, start building your application, inserting, updating, querying it...<p>- First job is to write a few abstractions that represent a row in each the tables in your db. It handles deserialising&#x2F;serialising from the database types to you languages types, plus a few of your custom types.<p>- You find yourself duplicating code for simple select&#x2F;update&#x2F;insert&#x2F;delete quires so you build another layer of abstraction so you have only one generic implementation of these that your table row abstractions use.<p>- You start writing more complex queries based on user input, it starts to get a little complex with all the string concatenation. You write a query builder for one area of you application, but soon find yourself longing to use it elsewhere. So you generalise it to be usable on other tables.<p>- Hand writing database migrations is simple to start with, but as your team grows, and you have more deployment environments, and more branches, it becomes a massive headache. Then one day someone runs the wrong migration and drops the main db... you write a database migration tool, reuse a bunch of your application table abstractions as the definitive source of truth for what your tables look like. Job done!<p>Oops, you wrote an ORM...<p>Obviously the world isn&#x27;t that simple, and there are legitimate reasons not to use one. But the majority of the time it&#x27;s better to start with an off the shelf ORM than not.<p>The issue with ORMs really come down to restrictions on escape hatches, easy dropping down to SQL but with mapping back to your higher level abstractions.