4 ms·
I do think this might have been true in the past, but SSDs have changed the game for databases. Databases became 10x faster over night but this hasn't sunk in t
by KingOfCoders 4y ago
I do think this might have been true in the past, but SSDs have changed the game for databases. Databases became 10x faster over night but this hasn't sunk in to every developer yet.
Also ORMs have created an environment, where bad queries are sent to the database for questionable gains (after saving time writing some initial code). After writing a nice Java ORM in the 90s myself (also wrote my own Ruby ORM framework called Ruby.RO before Rails became a thing), then using Hibernate/JPA extensively for a decade and later ORMs in Scala and TS.
I now prefer plain SQL (with Go). Quite often you can write some CTE that is fast but would have been several calls by an ORM. I also now use CTE to read/update/deleate data in one query (but be careful b/c execution order).
- ngc248 4y agoTrue ... I always preferred to roll my own DAL instead of an ORM, because when you actually get into the weeds, the kinda optimizations you can do with your own queries will always be better than what an ORM can do.
- norman784 4y ago> I now prefer plain SQL I don't know if Go is capable of, but Rust has a library called SQLx that does check that your SQL query at compile time (it makes the compilation slower than normal, but it's a good trade off I think), if this could done in Go it will be amazing too.
- KingOfCoders 4y agoYes I was using SQLx when writing Rust code and I've enjoyed it a lot.
- heurisko 4y ago> I now prefer plain SQL I prefer plain SQL using an ORM. Usually using the ORM for insertion, SQL for extraction. The ones I have used are not mutually exclusive (doctrine, hibernate).