3 ms·

The days of the ORM have passed. AI writes amazing SQL, modern SQL databases are incredible and the best way to get the most out of your DB is write SQL. Inve

The days of the ORM have passed. AI writes amazing SQL, modern SQL databases are incredible and the best way to get the most out of your DB is write SQL. Invest your learning budget in SQL, not in some random developers abstraction.

t-writescode 2y ago
A good ORM is just a pre-built and externally tested validator of common DB work. There's plenty of value in knowing both. "AI writes amazing SQL" and "AI writes amazing DB to Application Translation Layer Code" just means "AI can write your company's bespoke ORM".
benatkin 2y ago
AI can give better responses to a lot of requests when it has a well designed high level API available. And many ORMs don’t produce well designed APIs but it seems this one will.
- andrewstuart 2y ago
  Ai is as good as its training data and there’s vast sql documentation and source code that has been ingested by the AI engines.
  - benatkin 2y ago
    I think that for some things user intent would be better expressed as customized ORM than SQL queries. If the ORM isn’t customized and is just generated from the tables then, yeah, not much of a help.
randomdata 2y ago
You seem to be thinking of query builders. I would posit that they are still useful in many real-world scenarios because SQL still stupidly does not support composition. Maybe some day it will catch up with the 1950s, but until that day... ORM has nothing to do with queries. It is about the data. You will still want to map your database structures to your application structures (and vice-versa), else you'll end up with a weird and ugly chain of dependencies that will forever ruin your codebase.
- ndriscoll 2y ago
  What do you mean here? I'm my experience, SQL is one of the most compositional languages there is. You've got relations and a bunch of operations to combine and transform relations to form new relations.
  - randomdata 2y ago
    1. SQL has tables, not relations... 2. I may be misinterpreting you, but you seem to be talking about composition of data, while the rest of us are talking about the composition of the language. But, hopefully I've misinterpreted you. Perhaps you could demonstrate how query builder composition is best replaced in pure SQL?
    - ndriscoll 2y ago
      I'm not sure what distinction you're making besides allowing duplicate rows (which don't affect composition and you can remove with `distinct `). I'm also not sure how to answer your question. Obviously a query builder is just spitting out queries that you can just write yourself. In the best case, they're a thin wrapper to give different names to SQL (e.g. where vs filter, select vs map, join vs flatMap). Perhaps an example would be how frequently, ORMs encourage you to do a load-modify-save pattern that turns into multiple statements to execute. This is usually more code, more error-prone, and worse performing than just doing an UPDATE WHERE. If you need complex reporting with a dozen joins and several window functions, you'll also see how difficult it is to write similar code in an application. I'm not sure what you mean with composition of the language. The language consists of operators which you can chain together, and you can substitute expressions into each other to form larger expressions. E.g. you can join to a (select from where group by) expression in place of a table, and you can factor such things out into CTEs. What's not composable?
      - randomdata 2y ago
        > I'm not sure what distinction you're making besides allowing duplicate rows Duplicate rows, NULLs, ordering, etc. But there is no distinction to be made here, just calling attention to your grievous error so you don't make it again. We don't want to look like a fool again next time. Viva la education! > I'm also not sure how to answer your question. You put a lot of effort into a rather detailed response not once, but twice. You obviously know how to answer the question at a technical level, but perhaps you don't understand the nuance of my question? What I mean is: Show us some example code that demonstrates query builder composition and the pure SQL that you would use to replace it.

t-writescode 2y ago

A good ORM is just a pre-built and externally tested validator of common DB work. There's plenty of value in knowing both. "AI writes amazing SQL" and "AI writes amazing DB to Application Translation Layer Code" just means "AI can write your company's bespoke ORM".

benatkin 2y ago

AI can give better responses to a lot of requests when it has a well designed high level API available. And many ORMs don’t produce well designed APIs but it seems this one will.

andrewstuart 2y ago
Ai is as good as its training data and there’s vast sql documentation and source code that has been ingested by the AI engines.
- benatkin 2y ago
  I think that for some things user intent would be better expressed as customized ORM than SQL queries. If the ORM isn’t customized and is just generated from the tables then, yeah, not much of a help.

randomdata 2y ago

You seem to be thinking of query builders. I would posit that they are still useful in many real-world scenarios because SQL still stupidly does not support composition. Maybe some day it will catch up with the 1950s, but until that day... ORM has nothing to do with queries. It is about the data. You will still want to map your database structures to your application structures (and vice-versa), else you'll end up with a weird and ugly chain of dependencies that will forever ruin your codebase.

ndriscoll 2y ago
What do you mean here? I'm my experience, SQL is one of the most compositional languages there is. You've got relations and a bunch of operations to combine and transform relations to form new relations.
- randomdata 2y ago
  1. SQL has tables, not relations... 2. I may be misinterpreting you, but you seem to be talking about composition of data, while the rest of us are talking about the composition of the language. But, hopefully I've misinterpreted you. Perhaps you could demonstrate how query builder composition is best replaced in pure SQL?
  - ndriscoll 2y ago
    I'm not sure what distinction you're making besides allowing duplicate rows (which don't affect composition and you can remove with `distinct `). I'm also not sure how to answer your question. Obviously a query builder is just spitting out queries that you can just write yourself. In the best case, they're a thin wrapper to give different names to SQL (e.g. where vs filter, select vs map, join vs flatMap). Perhaps an example would be how frequently, ORMs encourage you to do a load-modify-save pattern that turns into multiple statements to execute. This is usually more code, more error-prone, and worse performing than just doing an UPDATE WHERE. If you need complex reporting with a dozen joins and several window functions, you'll also see how difficult it is to write similar code in an application. I'm not sure what you mean with composition of the language. The language consists of operators which you can chain together, and you can substitute expressions into each other to form larger expressions. E.g. you can join to a (select from where group by) expression in place of a table, and you can factor such things out into CTEs. What's not composable?
    - randomdata 2y ago
      > I'm not sure what distinction you're making besides allowing duplicate rows Duplicate rows, NULLs, ordering, etc. But there is no distinction to be made here, just calling attention to your grievous error so you don't make it again. We don't want to look like a fool again next time. Viva la education! > I'm also not sure how to answer your question. You put a lot of effort into a rather detailed response not once, but twice. You obviously know how to answer the question at a technical level, but perhaps you don't understand the nuance of my question? What I mean is: Show us some example code that demonstrates query builder composition and the pure SQL that you would use to replace it.