3 ms·

> ORMs by their nature end up duplicating the database schema in application code, resulting in multiple sources of truth that need to be synchronised. There i

> ORMs by their nature end up duplicating the database schema in application code, resulting in multiple sources of truth that need to be synchronised. There is always a duplication of "schema", both your database and application language need a definition of this. It then makes sense to have a tool to, as you say, synchronise this one way or the other. I prefer the ORM approach of the application code being the source of truth, but for others it's completely fair and aloud to go the other way. It comes down the type of work you do, the size and number of teams and who has ownership of the database and data.

Chris_Newton 4y ago
There is always a duplication of "schema", both your database and application language need a definition of this. Why can’t an application just run SQL queries directly against the database? I agree that there are many reasonable ways to manage a database, but not all of them involve reproducing the entire schema directly in client code the way an ORM does.
knome 4y ago
>who has ownership of the database and data I absolutely loathe projects that communicate via shared database. It completely ties the hands on everything that touches it. Data should be shared via an API, so that the underlying representation can be migrated, updated and changed and the API can munge up the new reality of the data to still look like the old. You should be able to switch between backends with a environment variable update, allowing your project to run in-memory, against sqlite, or against whatever actual relational or document store you plan to use in production. ORMs are "easier", in that they can get code running faster, but I've seen a good number of teams write the most atrocious code because the abstraction allows them to not think about things. Code that manages to fire tens of thousands of queries in loops instead of doing a single large query or walking the data in a conscious and efficient manner. It is my opinion that a single object inside of a project should wrap the database, each query thereto being represented by a function that, once again, can allow the underlying representation to change without the rest of the code being aware. ORMs are far too tightly bound, and teams using them likely to spatter ORM code all over the codebase instead of neatly arranging it behind a properly cut abstraction.

Chris_Newton 4y ago

There is always a duplication of "schema", both your database and application language need a definition of this. Why can’t an application just run SQL queries directly against the database? I agree that there are many reasonable ways to manage a database, but not all of them involve reproducing the entire schema directly in client code the way an ORM does.

knome 4y ago

>who has ownership of the database and data I absolutely loathe projects that communicate via shared database. It completely ties the hands on everything that touches it. Data should be shared via an API, so that the underlying representation can be migrated, updated and changed and the API can munge up the new reality of the data to still look like the old. You should be able to switch between backends with a environment variable update, allowing your project to run in-memory, against sqlite, or against whatever actual relational or document store you plan to use in production. ORMs are "easier", in that they can get code running faster, but I've seen a good number of teams write the most atrocious code because the abstraction allows them to not think about things. Code that manages to fire tens of thousands of queries in loops instead of doing a single large query or walking the data in a conscious and efficient manner. It is my opinion that a single object inside of a project should wrap the database, each query thereto being represented by a function that, once again, can allow the underlying representation to change without the rest of the code being aware. ORMs are far too tightly bound, and teams using them likely to spatter ORM code all over the codebase instead of neatly arranging it behind a properly cut abstraction.