5 ms·

I've never understood why programmers don't love SQL the language. It's the closest thing you can get to the silly voice interface they use in Sci-Fi: "Comput

I've never understood why programmers don't love SQL the language. It's the closest thing you can get to the silly voice interface they use in Sci-Fi: "Computer, give me a list of orders for red sweaters, but skip ones from customers who signed up more than 3 months ago" ... and it will figure out how to get you that list. And the syntax is so simple that you can do pretty much everything you'd ever want with six keywords. The query to get the list above is actually shorter than its English language description. Whenever I see some new ORM come out with its own way of asking for records from a database, a little question mark pops up over my head. Why would you do that? Did you really spend time building something to make your problem harder? Your code less elegant? Why why why? The only thing I can imagine is that people simply don't bother to learn SQL before deciding they don't like it. Too bad too, because writing queries is one of the most enjoyable bits of the software development game.

pilif 16y ago
Agreed. Personally, I really like SQL and whenever possible I'm going as much straight SQL skipping strange abstraction in ORM layers. Performance wise too, nothing beats hand-optimizing queries rather than hoping that the ORM of your choice doesn't decide that the particular method of retrieving the total value of a specific order will need one query per line item plus manually calculating the total.
sjs 16y ago
Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. [tangent] That's part of the attraction to NoSQL as well. You just serialize your objects to JSON or something else (probably already being done if you target the web). It's simple. Back to ORMs, you can't avoid SQL wrappers at least to help w/ injections, and you probably want a layer that serializes/deserializes your objects as well. Once you've written that a few times it's boring so you abstract it. ORMs are pretty much inevitable when writing the common web app. ORMs should borrow good things from SQL, like LINQ. Mainstream languages are better now than when SQL was created. I mean, it's not the exact syntax you like right? I prefer writing code rather than preparing and parsing strings. Plus if you ever decide to swap out the backend it's far easier when things are loosely coupled. SQL is akin to JS in the browser in that you need a library to abstract away the implementation differences or you'll be tightly coupled to a specific one. Maybe you don't need to run on all backends simultaneously but options are always nice. It all depends what the task is anyway though.
- jasonkester 16y ago
  Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. That's not unique to ORM. We don't use an ORM at Expat, yet all our objects still have .Load() and .Save() methods. I hope you didn't read my post to mean I advocate hand-writing your CRUD! I think LINQ is a great example of needlessly re-inventing something that wasn't very hard in the first place. Especially since its syntax is so close to SQL. Why not simply write your ad-hoc reports in SQL itself and save a lot of trouble?
  - heresy 16y ago
    LINQ is far more useful than just as language sugar over SQL. The amount of boilerplate it removes is substantial for anything working with sequences. I actually havent used the SQL backend for it. But since I often work with large collections of heterogenous data outside of a DB, I use it all the time to transform and filter collections in ways that would be very tedious in other languages. Libraries can get you some of the way there, but the language integration is what makes it so painless.
  - vyrotek 16y ago
    There's a lot of power and flexibility using a Model with LINQ. The strongly typed nature has saved me many times. When you alter a table and remove or rename a column you know exactly which queries are now broken at build time. If you were generating or hardcoding sql there's a chance that you hosed a lot of things and need to dig through all the code. Dynamically creating queries is amazing in LINQ. Building them with strongly typed expressions is much better than messy string concatenation.
    - jasonkester 16y ago
      Again, that's not unique to LINQ. Drop a db column in the thing we use and the project will fail to compile until you fix up the references. And of course, if you're keeping your stored procedures in source control and recompiling them at build time (which of course you should), you'll know when you break them too. As you say, strongly typed dataobjects are pretty cool. Regardless of how they interface with the database.
davidw 16y ago
Hey, that's my joke:-) I've always imagined one of the old Star Trek episodes where Kirk says "Computer, select course where Klingons equal to zero" or something to that effect.
DennisP 16y ago
I've been using SQL heavily for 12 years and mostly agree. The problem with SQL though is that it lacks abstractions. Any time you're forced to use dynamic SQL, the language has failed. For example: suppose you want to write a SQL script that populates a database with dummy data. There's no way to do it without dynamic sql, since SQL doesn't let you parameterize table and column names.
ant5 16y ago
I've never understood why programmers don't love SQL the language. Many programmers do love SQL. It's not a perfect solution, but it's better than most of the via alternatives. Anyone that "hates" SQL should be forced to read C.J. Date's Database in Depth, after which, if they still hate SQL, it will at least be for the right reasons. http://www.amazon.com/Database-Depth-Relational-Theory-Practitioners/dp/0596100124/ref=sr_1_8?ie=UTF8&s=books&qid=1279030623&sr=8-8 http://www.amazon.com/Database-Depth-Relational-Theory-Pract...
balding_n_tired 16y ago
SQL, or rather the relational model, is great for what it does. A thorough knowledge of both is central to most of what I've done over the last many years. But there are places where you don't really want named attributes with the names known beforehand, you want to generate new attributes, perhaps named on the fly, perhaps designated ordinally. The relational model doesn't really have room for this. The various flavors of SQL offer bolted-on ways to do this, incompatible & quite different. But it's a living...

pilif 16y ago

Agreed. Personally, I really like SQL and whenever possible I'm going as much straight SQL skipping strange abstraction in ORM layers. Performance wise too, nothing beats hand-optimizing queries rather than hoping that the ORM of your choice doesn't decide that the particular method of retrieving the total value of a specific order will need one query per line item plus manually calculating the total.

sjs 16y ago

Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. [tangent] That's part of the attraction to NoSQL as well. You just serialize your objects to JSON or something else (probably already being done if you target the web). It's simple. Back to ORMs, you can't avoid SQL wrappers at least to help w/ injections, and you probably want a layer that serializes/deserializes your objects as well. Once you've written that a few times it's boring so you abstract it. ORMs are pretty much inevitable when writing the common web app. ORMs should borrow good things from SQL, like LINQ. Mainstream languages are better now than when SQL was created. I mean, it's not the exact syntax you like right? I prefer writing code rather than preparing and parsing strings. Plus if you ever decide to swap out the backend it's far easier when things are loosely coupled. SQL is akin to JS in the browser in that you need a library to abstract away the implementation differences or you'll be tightly coupled to a specific one. Maybe you don't need to run on all backends simultaneously but options are always nice. It all depends what the task is anyway though.

jasonkester 16y ago
Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. That's not unique to ORM. We don't use an ORM at Expat, yet all our objects still have .Load() and .Save() methods. I hope you didn't read my post to mean I advocate hand-writing your CRUD! I think LINQ is a great example of needlessly re-inventing something that wasn't very hard in the first place. Especially since its syntax is so close to SQL. Why not simply write your ad-hoc reports in SQL itself and save a lot of trouble?
- heresy 16y ago
  LINQ is far more useful than just as language sugar over SQL. The amount of boilerplate it removes is substantial for anything working with sequences. I actually havent used the SQL backend for it. But since I often work with large collections of heterogenous data outside of a DB, I use it all the time to transform and filter collections in ways that would be very tedious in other languages. Libraries can get you some of the way there, but the language integration is what makes it so painless.
- vyrotek 16y ago
  There's a lot of power and flexibility using a Model with LINQ. The strongly typed nature has saved me many times. When you alter a table and remove or rename a column you know exactly which queries are now broken at build time. If you were generating or hardcoding sql there's a chance that you hosed a lot of things and need to dig through all the code. Dynamically creating queries is amazing in LINQ. Building them with strongly typed expressions is much better than messy string concatenation.
  - jasonkester 16y ago
    Again, that's not unique to LINQ. Drop a db column in the thing we use and the project will fail to compile until you fix up the references. And of course, if you're keeping your stored procedures in source control and recompiling them at build time (which of course you should), you'll know when you break them too. As you say, strongly typed dataobjects are pretty cool. Regardless of how they interface with the database.

davidw 16y ago

Hey, that's my joke:-) I've always imagined one of the old Star Trek episodes where Kirk says "Computer, select course where Klingons equal to zero" or something to that effect.

DennisP 16y ago

I've been using SQL heavily for 12 years and mostly agree. The problem with SQL though is that it lacks abstractions. Any time you're forced to use dynamic SQL, the language has failed. For example: suppose you want to write a SQL script that populates a database with dummy data. There's no way to do it without dynamic sql, since SQL doesn't let you parameterize table and column names.

ant5 16y ago

I've never understood why programmers don't love SQL the language. Many programmers do love SQL. It's not a perfect solution, but it's better than most of the via alternatives. Anyone that "hates" SQL should be forced to read C.J. Date's Database in Depth, after which, if they still hate SQL, it will at least be for the right reasons. http://www.amazon.com/Database-Depth-Relational-Theory-Practitioners/dp/0596100124/ref=sr_1_8?ie=UTF8&s=books&qid=1279030623&sr=8-8 http://www.amazon.com/Database-Depth-Relational-Theory-Pract...

balding_n_tired 16y ago

SQL, or rather the relational model, is great for what it does. A thorough knowledge of both is central to most of what I've done over the last many years. But there are places where you don't really want named attributes with the names known beforehand, you want to generate new attributes, perhaps named on the fly, perhaps designated ordinally. The relational model doesn't really have room for this. The various flavors of SQL offer bolted-on ways to do this, incompatible & quite different. But it's a living...