3 ms·

so your generalization is, "people who understand SQL really well would never use an ORM unless forced by their job". That is, you are claiming those who choos

by zzzeek 7y ago

so your generalization is, "people who understand SQL really well would never use an ORM unless forced by their job". That is, you are claiming those who choose to use ORMs must lack experience. This is what you have observed, in your experience. Can I therefore claim, since I know tons of SQL experts who use ORMs and even create new ones, that you "lack experience" as well? because your claim is wildly untrue. edit: i apologize for the snark but you are literally claiming a whole segment of the programming userbase is less experienced than you are, based on their choice of tools, while you aren't considering that perhaps you haven't worked with many of these kinds of tools to know what's really out there and how different ORMs approach the problem.

mywittyname 7y ago
Unless ORMs are 1:1 compatible with SQL features, some developers will inevitably be required to write SQL by hand. Lots of developers are happy to leverage stored procedures and let the database do heavy lifting to reduce network traffic (or whatever reason). Others prefer the database to simply be persistent storage for data structures and leave the logic to their Java/C++/PHP code. One of those camps will never be able to use ORMs, and the other may live by them. It stands to reason that more advanced SQL developers will leverage more advanced SQL features, some of which aren't available in ORM implementations.
- zzzeek 7y ago
  But that doesn't matter, you still can use tools to help compose the 90% of SQL that is quite boring Truth be told I think it is the "i write 100% of my SQL by hand" crowd that is still quite junior in their SQL experience. How many times would they like to write a rote INSERT statement over and over against their data records before realizing an abstraction would save them lots of typing and redundancy? Edit: also note that ORMs most certainly can be used with stored procedure architectures in theory. I'm not sure if such tools exist but if I had to use SPs, I'd be writing tools to both generate the SPs from a given set of models as well as to do the runtime work of marshaling my objects to and from these SPs from cursor.callproc() in the same way an ORM does it to plain SELECT / INSERT / UPDATE / DELETE statements from cursor.execute(). Additionally, systems like PostgreSQL's pluggable SP languages, which includes Python, might even allow SQLAlchemy models to work inside a stored procedure, something I've always wanted to try. Both concepts are things I'd gladly pursue if someone wanted to pay me a few years' salary.
- tomnipotent 7y ago
  > It stands to reason that more advanced SQL developers will leverage more advanced SQL features, I'm one of those advanced SQL developers, and an ORM has never gotten in my way. Don't blame the tool for the users lack of experience.
  - mywittyname 7y ago
    I'm not blaming anyone, I'm just pointing out that ORMs aren't going to have every SQL feature. Django didn't add windowing functions until rather recently. So while they are great for most use cases, but you're going to have to drop down to SQL if you want to use advanced features which are not available in your ORM of choice.
icxa 7y ago
I admit the comment was meant to be a bit tongue in cheek but it doesn't appear to have had that impact. My intention wasn't to be condescending or anything like that as others have taken it. A better argument would have been to explain why ORMs are bad. In my view: - they encourage bad data modeling practices. Eventually there will come a time where the way your ORM maps your data model to physical tables will be inefficient. Maybe you really have event based time series. The impedance mismatch becomes exacerbated. - they are an extremely leaky abstraction. It is hard to think of a more widely used abstraction that leaks more. You have to be familiar with your ORM's SQL generation. Every single comment here has admitted that yes you eventually do have to drop down into raw sql, so this part isn't even subjective at this point. The article is about leaky abstractions, ORMs are the poster child for them. - On the other side of things, there are simpler abstractions between SQL and ORM that provide more value comparatively for the leakage, and my argument was you would be better off having simple leaky abstractions than one massive behemoth of an abstraction that leaks more than a waterfall. - Really hammering the point home here on the leakiness, for being such a leaky abstraction, after it is all said and done, in my view they really don't provide you with all that much value, given that you have extensive experience working without them (the source of my seemingly condescending point about experience and some languages guide you to never working without them). I can just as easily use my code generation tools to have "less code to write", and map some functions to SQL statements using my language's favorite DB drivers, use a battle tested and proven SQL migration and schema tool, and I can do this just as fast as any experienced ORM developer. In this view, just like we have had the movement away from big massive monolithic frameworks to smaller opinionated sets of libraries stitched together with simple glue code, your ORM is the massive monolith in this case, and your simpler tools like code gen and migration tools are the smaller libraries.

by zzzeek 7y ago

mywittyname 7y ago

Unless ORMs are 1:1 compatible with SQL features, some developers will inevitably be required to write SQL by hand. Lots of developers are happy to leverage stored procedures and let the database do heavy lifting to reduce network traffic (or whatever reason). Others prefer the database to simply be persistent storage for data structures and leave the logic to their Java/C++/PHP code. One of those camps will never be able to use ORMs, and the other may live by them. It stands to reason that more advanced SQL developers will leverage more advanced SQL features, some of which aren't available in ORM implementations.

zzzeek 7y ago
But that doesn't matter, you still can use tools to help compose the 90% of SQL that is quite boring Truth be told I think it is the "i write 100% of my SQL by hand" crowd that is still quite junior in their SQL experience. How many times would they like to write a rote INSERT statement over and over against their data records before realizing an abstraction would save them lots of typing and redundancy? Edit: also note that ORMs most certainly can be used with stored procedure architectures in theory. I'm not sure if such tools exist but if I had to use SPs, I'd be writing tools to both generate the SPs from a given set of models as well as to do the runtime work of marshaling my objects to and from these SPs from cursor.callproc() in the same way an ORM does it to plain SELECT / INSERT / UPDATE / DELETE statements from cursor.execute(). Additionally, systems like PostgreSQL's pluggable SP languages, which includes Python, might even allow SQLAlchemy models to work inside a stored procedure, something I've always wanted to try. Both concepts are things I'd gladly pursue if someone wanted to pay me a few years' salary.
tomnipotent 7y ago
> It stands to reason that more advanced SQL developers will leverage more advanced SQL features, I'm one of those advanced SQL developers, and an ORM has never gotten in my way. Don't blame the tool for the users lack of experience.
- mywittyname 7y ago
  I'm not blaming anyone, I'm just pointing out that ORMs aren't going to have every SQL feature. Django didn't add windowing functions until rather recently. So while they are great for most use cases, but you're going to have to drop down to SQL if you want to use advanced features which are not available in your ORM of choice.

icxa 7y ago

I admit the comment was meant to be a bit tongue in cheek but it doesn't appear to have had that impact. My intention wasn't to be condescending or anything like that as others have taken it. A better argument would have been to explain why ORMs are bad. In my view: - they encourage bad data modeling practices. Eventually there will come a time where the way your ORM maps your data model to physical tables will be inefficient. Maybe you really have event based time series. The impedance mismatch becomes exacerbated. - they are an extremely leaky abstraction. It is hard to think of a more widely used abstraction that leaks more. You have to be familiar with your ORM's SQL generation. Every single comment here has admitted that yes you eventually do have to drop down into raw sql, so this part isn't even subjective at this point. The article is about leaky abstractions, ORMs are the poster child for them. - On the other side of things, there are simpler abstractions between SQL and ORM that provide more value comparatively for the leakage, and my argument was you would be better off having simple leaky abstractions than one massive behemoth of an abstraction that leaks more than a waterfall. - Really hammering the point home here on the leakiness, for being such a leaky abstraction, after it is all said and done, in my view they really don't provide you with all that much value, given that you have extensive experience working without them (the source of my seemingly condescending point about experience and some languages guide you to never working without them). I can just as easily use my code generation tools to have "less code to write", and map some functions to SQL statements using my language's favorite DB drivers, use a battle tested and proven SQL migration and schema tool, and I can do this just as fast as any experienced ORM developer. In this view, just like we have had the movement away from big massive monolithic frameworks to smaller opinionated sets of libraries stitched together with simple glue code, your ORM is the massive monolith in this case, and your simpler tools like code gen and migration tools are the smaller libraries.