5 ms·

Stop using SQL already. We now have at least 4 decades of experience with them and found out that they are a suboptimal solution to the problem. Just use an OR

Stop using SQL already. We now have at least 4 decades of experience with them and found out that they are a suboptimal solution to the problem. Just use an ORM or any other kind of library that removes the boilerplate and is 100x more maintainable and productive. See how useful it is to not explain anything.

valenterry 6y ago
My post is provocative and not explaining, true. However, your comparison does not make sense. JOOQ and similar libraries don't make you write SQL, even if their API is closer to SQL than what most ORMs do. If you replace "ORM" in your example with NoSQL or some other technology that directly competes with SQL then it would make sense.
DJBunnies 6y ago
I've never seen an orm work 100% correctly though, with indexes/pagination/etc. Far easier to write correct sql than to convince the orm how to form correct sql.
- pantelisk 6y ago
  ORMs seem amazing up until the inevitable point of hitting a performance issue or bug, and having to print the underlying statement. At that point you are no longer fighting with the bug impacting your systems, you are fighting with the ORM midddle-ware it self, and having to quickly improve your SQL competency above everything else. That is the moment you 've lost all the benefits advertised. For smaller systems it might be ok I guess, but stay alive long enough and you 'll see that sooner or later every small system desires to grow, grow and grow!
  - bsaul 6y ago
    the way to debug performance on a large sql system is to log things on the sql server itself and monitor for weird queries. Tjis is part of monitoring a db and this has to be done no matter which tech you used to generate those queries. good ORMs all have a way to fine-control the underlying statements to avoid querying individual rows one by one. I'm fairly proficient with sql queries and i still don't like writing sql queries and binding to objects manually
  - balfirevic 6y ago
    > That is the moment you 've lost all the benefits advertised. No, that makes no sense. If you have to investigate 2 places where performance issues have cropped up and hand-write the SQL in those places, while 95% of your application works just fine, how did you lose all the benefits? My SQL competency was fine from the beginning, thank you very much.
    - deleted 6y ago
      [deleted]
tomas789 6y ago
It might be just my experience but when using ORMs I just constantly think of how to write a SQL query in my head using the ORMs syntax. As a result I’m usually using ORMs for schema maintenance and inserts. For getting the data out of the DB SQL is a simple way to go. Just my experience so far.

valenterry 6y ago

My post is provocative and not explaining, true. However, your comparison does not make sense. JOOQ and similar libraries don't make you write SQL, even if their API is closer to SQL than what most ORMs do. If you replace "ORM" in your example with NoSQL or some other technology that directly competes with SQL then it would make sense.

DJBunnies 6y ago

I've never seen an orm work 100% correctly though, with indexes/pagination/etc. Far easier to write correct sql than to convince the orm how to form correct sql.

pantelisk 6y ago
ORMs seem amazing up until the inevitable point of hitting a performance issue or bug, and having to print the underlying statement. At that point you are no longer fighting with the bug impacting your systems, you are fighting with the ORM midddle-ware it self, and having to quickly improve your SQL competency above everything else. That is the moment you 've lost all the benefits advertised. For smaller systems it might be ok I guess, but stay alive long enough and you 'll see that sooner or later every small system desires to grow, grow and grow!
- bsaul 6y ago
  the way to debug performance on a large sql system is to log things on the sql server itself and monitor for weird queries. Tjis is part of monitoring a db and this has to be done no matter which tech you used to generate those queries. good ORMs all have a way to fine-control the underlying statements to avoid querying individual rows one by one. I'm fairly proficient with sql queries and i still don't like writing sql queries and binding to objects manually
- balfirevic 6y ago
  > That is the moment you 've lost all the benefits advertised. No, that makes no sense. If you have to investigate 2 places where performance issues have cropped up and hand-write the SQL in those places, while 95% of your application works just fine, how did you lose all the benefits? My SQL competency was fine from the beginning, thank you very much.
  - deleted 6y ago
    [deleted]

tomas789 6y ago

It might be just my experience but when using ORMs I just constantly think of how to write a SQL query in my head using the ORMs syntax. As a result I’m usually using ORMs for schema maintenance and inserts. For getting the data out of the DB SQL is a simple way to go. Just my experience so far.