Either way, everything gets easier with a simple schema. Faster query and insert performance, easier to reason about when doing transactions, easier to maintain, etc.
Don't use your ORM entities for everything – embrace the SQL
11–20 of 48 posts
Re: Don't use your ORM entities for everything – embrace the SQL
#12The article mentions database portability as an advantage of ORMs, and I agree - to me that is basically the only real advantage to ORMs. The article also mentions that database portability is not a very compelling advantage, since lots of applications don't actually need that, which I also agree with. Personally I just pick either PostgreSQL or SQLite depending on my use case (and they're different enough that there…
Re: Don't use your ORM entities for everything – embrace the SQL
#13Yes, use sqlite locally for development and run PG in prod. Unit tests can now use the db and finish in milliseconds. You get unit tests that have the power of integration tests and don't have to ever stub out your db. I use Redislite for the same thing.
I'm of the opinion that SQLite is the musl of the SQL world. By deciding that you'll support it first-class you'll avoid the sharp edges of database specific behavior and extension hell and write better more maintainable code.
"Sorry we can't actually put that logic the database, SQLite doesn't support spooky action at a distance."
Re: Don't use your ORM entities for everything – embrace the SQL
#14Re: Don't use your ORM entities for everything – embrace the SQL
#15Most IDEs provide intellisense/validation of ORM entities, vs treating SQL like a raw string.
ORM entities also make refactoring and impact analysis slightly easier.
Despite those benefits, I generally find ORMs a pain for anything besides the most basic queries.
Re: Don't use your ORM entities for everything – embrace the SQL
#16Re: Don't use your ORM entities for everything – embrace the SQL
#17I still don't understand why people believe that abstracting away something as important as your data store is a good idea. They quickly run into performance problems that are quite difficult to fix. It's funny that the same developers that try to avoid vendor lock-in don't realize they've locked themselves into an ORM forever. Plus, SQL isn't that hard. And as a backend person, you should be able to visualize your d…
We use Kysely[0], which is a nice balance. The code you write in Kysely translates 1:1 into SQL, which means there's very little perf left on the table, but we get an interface that's automatically typed, type safe, and works well with our js language tools. [0]: https://kysely.dev/
Re: Don't use your ORM entities for everything – embrace the SQL
#18Comments here make me wonder if I've just been spoiled by ActiveRecord. Not that I use it for all queries but 1) it's rare that I have to resort to raw SQL and 2) it kindly gets out of the way when I do.
I'm the opposite, I would rather write SQL than "resorting to" ORM queries, which is why my favourite libraries are aiosql[1] in Python, Hugsql[2] in Clojure and similar: write the queries as SQL in .sql files, which then get exposed as functions to your code.
Re: Don't use your ORM entities for everything – embrace the SQL
#19Re: Don't use your ORM entities for everything – embrace the SQL
#20But we still only have one language for querying a database. And a kinda not very good one at that. Why is that?
https://www.holistics.io/blog/quel-vs-sql/
One could argue that ORM's are the alternative language people are looking for.