131–139 of 139 posts
Earlier quoted context omitted.
Every single time. Where are these developers? Orms are a god send 98% of the time. Sure, write some SQL from time to time, but the majority of the time just use the ORM.
> Orms are a god send 98% of the time. People who write percentages make shit up 98% of the time. Or in other words: Source?
My only problem with SQL is it was designed for human input (same as shell commands), not for machines. Hence the SQL Injection attacks and other peculiarities and inefficiencies. IMO for machine-to-machine talk we should not be using a long text that needs to be parsed carefully and securely on the other side, but rather a structured structure that's easy to de-serialize (like AST packed into a protobuf, but for SQL…
You'd have to be using very antiquated (by nearly two decades!) patterns or practices for SQL injection to be a concern.
And subling commenters say that all you need is raw SQL and results mapping to your code. Which I did for a while, but found that mapping is a lot of copy-pasta with minor diffs, a burden to maintain. So it's easier to use a thin library like JOOQ for mapping, or use only the mapper part of a bigger ORM framework like Django/Hibernate.
And my argument is that it's easier to map to/from a concise strongly-typed ABI/API structs instead of one raw SQL string with its structure designed for human reading/writing, like SELECT before FROM. There are such ABI-s, but they are DBMS-specific, while SQL is less so.
I notice that the top image is of Transact SQL, the Sybase/Microsoft dialect. This is not a formal standard, and I suggest against its use. https://en.wikipedia.org/wiki/Transact-SQL SQL/PSM is a general ISO standard that grew out of Oracle PL/SQL, is rooted in ADA, and is implemented by a large range of databases. https://en.wikipedia.org/wiki/SQL/PSM Standards are important.
The SQL standard defines more of an aesthetic than an actual language. Every database just extends it arbitrarily and anything beyond rudimentary queries is borderline guaranteed to be incompatible with other databases. When it comes to procedural logic in particular… you have almost zero chance you’re dropping into that into another database and it working — even for rudimentary usage. SQL-land is utterly revolting…
I was aware that EnterpriseDB developed "deep Oracle compatibility" and sold the resulting code to IBM for Db2 several years ago.
I think you are [more than] a bit behind the times?
https://www.cnet.com/culture/ibm-puts-oracle-to-the-sword-wi...
The mere existence of Pandas makes me extremely grateful for SQL, because my job would be absolute hell if I had to use pandas or a similar syntax. It’s hard to overemphasize just how perfect SQL is for the job that it does.
I don't think SQL is "perfect" and I'm not sure it's rational to even be saying that. For instance, why is it that the syntax for an SQL query is "select A from B" when many SQL-inspired syntaxes have switched to something like "from B select A" to make it more compositional? The relational model is pretty simple though. Pandas is an awful mess.
Earlier quoted context omitted.
What is your definition of 'programming language'?
It should have arrays, and loops and conditionals.
select 1+1; -- Result: 2
That's the key difference.
I've loved and used Django ORM and SQLAlchemy for many years. It got me a long way in my career. But at this point I've sworn-off using query-builders and ORMs. I just write real, hand-crafted SQL now. These "any db" abstractions just make for the worst query patterns. They're easy and map nicely to your application language, but they're really terrible unless you want to put in the effort to meta-program SQL using w…
Anytime this topic comes up, this opinion is invariably at the top of the comments. However I've never seen a non-trivial application made this way. Mind sharing one? More than the query generation, I think people reach for ORMs for static typing, mapping, migrations, transactions, etc. I'm not doubting that it can be done, I'm just curious to see how it's done.
Also, in many non-tech companies the database admins were historically a consistent IT resource even when no other developers were available, so SQL gets leveraged extensively. When your only tool is a hammer, most of your problems end up being weirdly nail shaped.
I've loved and used Django ORM and SQLAlchemy for many years. It got me a long way in my career. But at this point I've sworn-off using query-builders and ORMs. I just write real, hand-crafted SQL now. These "any db" abstractions just make for the worst query patterns. They're easy and map nicely to your application language, but they're really terrible unless you want to put in the effort to meta-program SQL using w…
I love SQL and use it all day long to answer various business questions, but I would never use raw SQL in my code unless there is a good reason for it (sometimes there is). ORMs are there for maintainability, composability, type safety, migrations, etc.. trying to do all that with raw SQL strings doesn't scale in a large code base. You need something that IDE tools can understand and allow things like 'find all refer…
That in itself is fine, of course. Less fine is the author's thoughtless assumption that their readers are all learning about it too.
Earlier quoted context omitted.
I love SQL and use it all day long to answer various business questions, but I would never use raw SQL in my code unless there is a good reason for it (sometimes there is). ORMs are there for maintainability, composability, type safety, migrations, etc.. trying to do all that with raw SQL strings doesn't scale in a large code base. You need something that IDE tools can understand and allow things like 'find all refer…
Sounds like your issue is writing the complex SQL all as strings in your codebase instead of as functions in the database.