4 ms·

An ORM is not too much pre optimisation…

crabmusket 3y ago
Yeah MVPs and mockups is exactly what ORMs are for, since they get you the first 80% for very little effort. Maybe it depends on the language, but this is definitely the way Rails and Laravel style framework ORMs are designed.
- mewpmewp2 3y ago
  To me SQL is better for MVPs. It is transparent and clear, easy to debug and can do easily whatever joins, filtering you want to. ORM is more for future, because it abstracts away the database implementation, so you could in theory change the db or change some behaviour more simply. E.g. if you add something like deleted_at column, ORM can have a single place where to configure system to use it, but if you have SQL queries lying around you may need to find all spots to add that to your where clauses everywhere. But otherwise SQL is easier to work with in my view.
  - crabmusket 3y ago
    What ORMs/languages do you usually work with? Dynamic language ORMs usually let you very easily add filters, work with relationships, etc.
    - mewpmewp2 3y ago
      I started out with Laravel 10 years ago, but now I have been in the NodeJS Ecosystem for recent 5 years, so I've been working with different things, but lately mostly with Supabase, which has its own REST API abstraction, but now I've been lately starting to prefer just having a direct bare postgres client against it. This is for my own side projects/MVPs.
    - alexanderchr 3y ago
      Yeah I’ve found both Eloquent (Laravel ORM) and Entity Framework to be more than flexible enough and to produce surprisingly good SQL. You do need to keep an eye on the queries if produces though because innocent changes can make a huge difference in performance.
mewpmewp2 3y ago
ORMs can be annoying to use in my experience, especially with more complex queries, joins, counts, filtering by joins etc. And they make debugging harder usually.
- dgan 3y ago
  I don't know, i don't think ever came across something I wasn't able to express in SQLAlchemy... And I prefer all the goodies that come with it than writing raw sql
- speleding 3y ago
  Since I found out that ChatGPT does a really nice job of "Show me what ActiveRecord query would generate this SQL query", and vice versa, it's gotten quite a bit easier. It handles some surprisingly complex stuff
- randomdata 3y ago
  There is no avoiding object-relational mapping, though, unless you intend to carry relations (sets of tuples) from start to finish. Something you almost certainly cannot do if you interface with any third-party code – which will expect language-native structures. It's just a question of whether you want to use a toolkit to help the transformations, or if you want to 'do it by hand'.

Yeah MVPs and mockups is exactly what ORMs are for, since they get you the first 80% for very little effort. Maybe it depends on the language, but this is definitely the way Rails and Laravel style framework ORMs are designed.

mewpmewp2 3y ago
To me SQL is better for MVPs. It is transparent and clear, easy to debug and can do easily whatever joins, filtering you want to. ORM is more for future, because it abstracts away the database implementation, so you could in theory change the db or change some behaviour more simply. E.g. if you add something like deleted_at column, ORM can have a single place where to configure system to use it, but if you have SQL queries lying around you may need to find all spots to add that to your where clauses everywhere. But otherwise SQL is easier to work with in my view.
- crabmusket 3y ago
  What ORMs/languages do you usually work with? Dynamic language ORMs usually let you very easily add filters, work with relationships, etc.
  - mewpmewp2 3y ago
    I started out with Laravel 10 years ago, but now I have been in the NodeJS Ecosystem for recent 5 years, so I've been working with different things, but lately mostly with Supabase, which has its own REST API abstraction, but now I've been lately starting to prefer just having a direct bare postgres client against it. This is for my own side projects/MVPs.
  - alexanderchr 3y ago
    Yeah I’ve found both Eloquent (Laravel ORM) and Entity Framework to be more than flexible enough and to produce surprisingly good SQL. You do need to keep an eye on the queries if produces though because innocent changes can make a huge difference in performance.

mewpmewp2 3y ago

ORMs can be annoying to use in my experience, especially with more complex queries, joins, counts, filtering by joins etc. And they make debugging harder usually.

dgan 3y ago
I don't know, i don't think ever came across something I wasn't able to express in SQLAlchemy... And I prefer all the goodies that come with it than writing raw sql
speleding 3y ago
Since I found out that ChatGPT does a really nice job of "Show me what ActiveRecord query would generate this SQL query", and vice versa, it's gotten quite a bit easier. It handles some surprisingly complex stuff
randomdata 3y ago
There is no avoiding object-relational mapping, though, unless you intend to carry relations (sets of tuples) from start to finish. Something you almost certainly cannot do if you interface with any third-party code – which will expect language-native structures. It's just a question of whether you want to use a toolkit to help the transformations, or if you want to 'do it by hand'.