6 ms·

Here's a thought experiment. Lets say we lived in a world without SQL and the default way to talk to DB's was through an ORM.... And then someone came and said

by dicroce 12y ago

Here's a thought experiment. Lets say we lived in a world without SQL and the default way to talk to DB's was through an ORM.... And then someone came and said: "I created this concise and super flexible language for querying data." Would people want it? I think they would, and we'd see tons of articles about vast forests of objects being replaced by small snippets of SQL.

bitwize 12y ago
There is another theory which states that this has already happened. See: ISAM databases as found in COBOL programs.
- maaku 12y ago
  The problem was SQL got standardized, and became static. There is so much room for innovation in the database language space, but that would mean breaking compatibility with the SQL standards...
  - dragonwriter 12y ago
    > The problem was SQL got standardized, and became static. SQL hasn't been static since it was first standardized, much like C++ hasn't. However, there's may be a good case that many of the central, underlying design decisions that are by now difficult to extract without tossing the whole thing overboard could have been done better with the benefit of several decades more experience in PL design and understanding of how databases are used.
glhaynes 12y ago
"Object-oriented programming is great. It's what's enabled developers to create the vast world of amazing applications available today. But there's an impedance mismatch between OOP and relational databases. That's why today we're reinventing database access. Say hello to SQL."
- nesyt 12y ago
  If it was released today, they would skip the awkward do-i-spell-it-out-or-do-i-add-vowels part in favor of the catchy-but-meaningless-project-name and just call it Sequel. Then they could be fresh and say it's the "sequel" to ORM. (Though you might go for Seequill or something so people could google it.)
  - wickawic 12y ago
    From Wikipedia: "...SEQUEL (Structured English Query Language), was designed to manipulate and retrieve data stored in IBM's original quasi-relational database...The acronym SEQUEL was later changed to SQL because "SEQUEL" was a trademark of the UK-based Hawker Siddeley aircraft company."
    - nesyt 12y ago
      Huh. Interesting. That'll teach me to make jokes without consulting the history books.
dragonwriter 12y ago
> And then someone came and said: "I created this concise and super flexible language for querying data." Would people want it? Sure, but if we're going to imagine that, hopefully it looks a lot more like a D [1] than like SQL. [1] As described in The Third Manifesto, http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-2013-02-07.pdf http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-2013-02-07.pdf
Daishiman 12y ago
When I look at SQL through the lenses of hindsight I see a language that's not amenable to IDEs (it's harder to autocomplete columns if you must write those before the table name, as an example), and has questionable and verbose syntax. While straight relational algebra is actually quite readable, despite all the efforts of most the anti-ORM crowd, at the end of the day the business logic that works on business objects is much more important than the storage backend, and thinking in terms of objects seems to be the preferred alternative when reasoning in that context. I've been doing backend logic for quite a while now, and I have to say that the special features RDBMs offer are great for reporting, but reporting is a very, very small part of what most code that interacts with the business domain does. And while that may be because SQL is great at aggregating data, the fact that it can't easily be plugged with the rest of my business logic is a huge impediment. This wouldn't be a problem if my entire business logic were to reside in the database, but real world applications interact with external APIs, regular files, and a whole other bunch of stuff. So the fact that ORMs speak the language of my business logic is a far greater advantage. I also find the argument of inefficiency to be a strawman. Well-written ORMs are quite explicit (and lazy) about what they're doing, and standard best practices would dictate that you should be properly describing the scopes and fields you're fetching when your rows become wide enough. But SQL demands that too; you can trivially fetch * from a table. And SQL's limitations mean that you don't have access to all the sweet abbreviations ORMs provide such as scopes, custom query managers, aliases, built-in result caches, and being able to avoid the worst cases of vendor-specific SQL. I started using ORMs because I was tired of writing the same SELECT statement with 10 slight variations, stored in a source file for a different language, having to deal with row casting, and being unable to plug in simple code to fetch related entities. SQL thus far has not advanced one bit in this area, and until someone comes up with a way to modularize the language so it can provide those features, purists will still complain while most of us keep using ORMs to avoid verbosity, bugs, and compatiblity problems.
- taeric 12y ago
  I question the claim that reporting is a small part of what interactions with the business domain is about. For many shops, I'd wager the opposite claim is true, honestly. Of course, there is a very thin line between "reporting" and "transforming to better deal with explorational algorithm." That is to say, my assertion is that it is when folks try and come up with "one true model" of their data that thing start to suck. Whether in ORM land or straight SQL land. Or just flat out "in memory" land, honestly.

by dicroce 12y ago

bitwize 12y ago

There is another theory which states that this has already happened. See: ISAM databases as found in COBOL programs.

maaku 12y ago
The problem was SQL got standardized, and became static. There is so much room for innovation in the database language space, but that would mean breaking compatibility with the SQL standards...
- dragonwriter 12y ago
  > The problem was SQL got standardized, and became static. SQL hasn't been static since it was first standardized, much like C++ hasn't. However, there's may be a good case that many of the central, underlying design decisions that are by now difficult to extract without tossing the whole thing overboard could have been done better with the benefit of several decades more experience in PL design and understanding of how databases are used.

glhaynes 12y ago

"Object-oriented programming is great. It's what's enabled developers to create the vast world of amazing applications available today. But there's an impedance mismatch between OOP and relational databases. That's why today we're reinventing database access. Say hello to SQL."

nesyt 12y ago
If it was released today, they would skip the awkward do-i-spell-it-out-or-do-i-add-vowels part in favor of the catchy-but-meaningless-project-name and just call it Sequel. Then they could be fresh and say it's the "sequel" to ORM. (Though you might go for Seequill or something so people could google it.)
- wickawic 12y ago
  From Wikipedia: "...SEQUEL (Structured English Query Language), was designed to manipulate and retrieve data stored in IBM's original quasi-relational database...The acronym SEQUEL was later changed to SQL because "SEQUEL" was a trademark of the UK-based Hawker Siddeley aircraft company."
  - nesyt 12y ago
    Huh. Interesting. That'll teach me to make jokes without consulting the history books.

dragonwriter 12y ago

> And then someone came and said: "I created this concise and super flexible language for querying data." Would people want it? Sure, but if we're going to imagine that, hopefully it looks a lot more like a D [1] than like SQL. [1] As described in The Third Manifesto, http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-2013-02-07.pdf http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-2013-02-07.pdf

Daishiman 12y ago

When I look at SQL through the lenses of hindsight I see a language that's not amenable to IDEs (it's harder to autocomplete columns if you must write those before the table name, as an example), and has questionable and verbose syntax. While straight relational algebra is actually quite readable, despite all the efforts of most the anti-ORM crowd, at the end of the day the business logic that works on business objects is much more important than the storage backend, and thinking in terms of objects seems to be the preferred alternative when reasoning in that context. I've been doing backend logic for quite a while now, and I have to say that the special features RDBMs offer are great for reporting, but reporting is a very, very small part of what most code that interacts with the business domain does. And while that may be because SQL is great at aggregating data, the fact that it can't easily be plugged with the rest of my business logic is a huge impediment. This wouldn't be a problem if my entire business logic were to reside in the database, but real world applications interact with external APIs, regular files, and a whole other bunch of stuff. So the fact that ORMs speak the language of my business logic is a far greater advantage. I also find the argument of inefficiency to be a strawman. Well-written ORMs are quite explicit (and lazy) about what they're doing, and standard best practices would dictate that you should be properly describing the scopes and fields you're fetching when your rows become wide enough. But SQL demands that too; you can trivially fetch * from a table. And SQL's limitations mean that you don't have access to all the sweet abbreviations ORMs provide such as scopes, custom query managers, aliases, built-in result caches, and being able to avoid the worst cases of vendor-specific SQL. I started using ORMs because I was tired of writing the same SELECT statement with 10 slight variations, stored in a source file for a different language, having to deal with row casting, and being unable to plug in simple code to fetch related entities. SQL thus far has not advanced one bit in this area, and until someone comes up with a way to modularize the language so it can provide those features, purists will still complain while most of us keep using ORMs to avoid verbosity, bugs, and compatiblity problems.

taeric 12y ago
I question the claim that reporting is a small part of what interactions with the business domain is about. For many shops, I'd wager the opposite claim is true, honestly. Of course, there is a very thin line between "reporting" and "transforming to better deal with explorational algorithm." That is to say, my assertion is that it is when folks try and come up with "one true model" of their data that thing start to suck. Whether in ORM land or straight SQL land. Or just flat out "in memory" land, honestly.