4 ms·

All the anti-sql bitching can be summed up in one sentence: "what do you mean I have to learn a complex tool in order to use it?!". Yet somehow most developer g

by DenisM 17y ago

All the anti-sql bitching can be summed up in one sentence: "what do you mean I have to learn a complex tool in order to use it?!". Yet somehow most developer got over "what do you mean you have to learn about algorithms and data structures before you can actually program?", but this other one seems like an insurmountable obstacle to a great (and vocal) many. It's really tiresome.

DavidMcLaughlin 17y ago
> Yet somehow most developer got over "what do you mean you have to learn about algorithms and data structures before you can actually program?" I respectfully disagree.
- DenisM 17y ago
  No one who says the quoted above will be treated seriously around here. Yet the other one seems to be entirely acceptable.
weavejester 17y ago
I think you're putting up something of a straw man. There may be some people who dislike SQL because it is too complex, but there are plenty of valid reasons to dislike it as well. SQL is not a particularly well thought-out language, and the relational model does not suit all problems.
- akronim 17y ago
  It's not SQL that's complex, it's mastering the details of an RDBMS to get the desired performance and scale. This heads towards dba/sysadmin territory which IS complex if that's not your speciality.
- DenisM 17y ago
  No solution suites all problems. Does it even need to be mentioned? SQL is not a particularly well thought-out language Uhm, that not a very substantiative argument - care to clarify? Bear in mind that the structure of the language is 100% dictated by the Relational Algebra - form follows function to the letter. And the very constraints that algebra puts on what you can do are the same constraints that allow the system to function based on your intent, so that you don't need to define or in most cases even chose the algorithms. The only wiggle room you have in designing a language based on relational algebra is the choice of tokens and ordering of language constructs (e.g. FROM before SELECT of after). So?
  - weavejester 17y ago
    SQL is based on relational algebra, but does not strictly follow it. For instance, each tuple in a relation is unique; but an SQL table can have identical rows. So firstly, SQL isn't a language that is "100% dictated by relational algebra". But even if it were, the syntax is still poorly thought out. There's no consistency in SQL; each command has its own grammar. You "SELECT ... FROM" and then "INSERT INTO ...". Command syntax is effectively arranged at random. Worse, there's no extensibility. Most programming languages, when faced with the problem of manipulating data, make use of functions. Instead of having specific syntax for selecting columns or filtering by a condition, a more sensible approach would be to make them functions that lazily transform tables. Then the user could define their own operations, and we'd no longer need to generate a page of SQL each time we wanted to do something complex. Next problem; integration with calling languages. SQL is not designed to integrate well with ORMs or other client libraries. We either want a language that's basically little more than a serialized AST, or take an approach similar to CouchDB, and farm out specific calculations to some server or library running our programming language of choice. Finally; optimization opaqueness. It can often be difficult to predict how the database server will optimize a particular piece of SQL. It might be useful if we could drop down to more primitive, but more predictable, operations when necessary. In short, I think that if a relational database system were to be designed from scratch by experienced programmers, it would look very different to the SQL databases that are around today.
    - DenisM 17y ago
      You can achieve function-like behavior for vertical or horizontal slicing of tables by using views - I use them all the time, and mine are updateable. Some vendors allow parametrized views, e.g. Table Valued Functions in MS SQL (sadly those aren't updateable I think?) and Common Table Subexpressions. Between these three spaghetti SQL doesn't have to exist. I spent a lot of time writing SQL and the ordering of SELECT ... FROM doesn't bother me at all. Frankly, I find this argument silly and I do not want to entertain it - when buying offroad SUV I will only compare the color of door handles when all else is equal, which it isn't. The only serious part of it is intellisense problems which admittedly could use some work (this is why LINQ is the other way around - table name is always spelled first). The other two points are entirely valid. The integration is a real pain. The opaqueness can be mitigated by vendors as well - MSSSQL allows hints to force desired behavior - but that doesn't so much drop down in abstraction level as it bastardizes the existing one.
- bartl 17y ago
  >but there are plenty of valid reasons to dislike it The reason why I don't like SQL much, is not because of SQL itself, but because of its poor fit into the host programming language. In PL-SQL, Oracle's own programming language, the SQL statements are simply part of the program. That is how it should be. But in other languages (like Perl), the SQL is like code you need to `eval` at runtime. There is no syntax check until you actually run it. And that makes it cumbersome to work with. Plus, you often have to do optimizations (like to separate `prepare` from the rest of the code) by hand, which only makes it worse. It's all just very low level.

by DenisM 17y ago

DavidMcLaughlin 17y ago

> Yet somehow most developer got over "what do you mean you have to learn about algorithms and data structures before you can actually program?" I respectfully disagree.

DenisM 17y ago
No one who says the quoted above will be treated seriously around here. Yet the other one seems to be entirely acceptable.

weavejester 17y ago

I think you're putting up something of a straw man. There may be some people who dislike SQL because it is too complex, but there are plenty of valid reasons to dislike it as well. SQL is not a particularly well thought-out language, and the relational model does not suit all problems.

akronim 17y ago
It's not SQL that's complex, it's mastering the details of an RDBMS to get the desired performance and scale. This heads towards dba/sysadmin territory which IS complex if that's not your speciality.
DenisM 17y ago
No solution suites all problems. Does it even need to be mentioned? SQL is not a particularly well thought-out language Uhm, that not a very substantiative argument - care to clarify? Bear in mind that the structure of the language is 100% dictated by the Relational Algebra - form follows function to the letter. And the very constraints that algebra puts on what you can do are the same constraints that allow the system to function based on your intent, so that you don't need to define or in most cases even chose the algorithms. The only wiggle room you have in designing a language based on relational algebra is the choice of tokens and ordering of language constructs (e.g. FROM before SELECT of after). So?
- weavejester 17y ago
  SQL is based on relational algebra, but does not strictly follow it. For instance, each tuple in a relation is unique; but an SQL table can have identical rows. So firstly, SQL isn't a language that is "100% dictated by relational algebra". But even if it were, the syntax is still poorly thought out. There's no consistency in SQL; each command has its own grammar. You "SELECT ... FROM" and then "INSERT INTO ...". Command syntax is effectively arranged at random. Worse, there's no extensibility. Most programming languages, when faced with the problem of manipulating data, make use of functions. Instead of having specific syntax for selecting columns or filtering by a condition, a more sensible approach would be to make them functions that lazily transform tables. Then the user could define their own operations, and we'd no longer need to generate a page of SQL each time we wanted to do something complex. Next problem; integration with calling languages. SQL is not designed to integrate well with ORMs or other client libraries. We either want a language that's basically little more than a serialized AST, or take an approach similar to CouchDB, and farm out specific calculations to some server or library running our programming language of choice. Finally; optimization opaqueness. It can often be difficult to predict how the database server will optimize a particular piece of SQL. It might be useful if we could drop down to more primitive, but more predictable, operations when necessary. In short, I think that if a relational database system were to be designed from scratch by experienced programmers, it would look very different to the SQL databases that are around today.
  - DenisM 17y ago
    You can achieve function-like behavior for vertical or horizontal slicing of tables by using views - I use them all the time, and mine are updateable. Some vendors allow parametrized views, e.g. Table Valued Functions in MS SQL (sadly those aren't updateable I think?) and Common Table Subexpressions. Between these three spaghetti SQL doesn't have to exist. I spent a lot of time writing SQL and the ordering of SELECT ... FROM doesn't bother me at all. Frankly, I find this argument silly and I do not want to entertain it - when buying offroad SUV I will only compare the color of door handles when all else is equal, which it isn't. The only serious part of it is intellisense problems which admittedly could use some work (this is why LINQ is the other way around - table name is always spelled first). The other two points are entirely valid. The integration is a real pain. The opaqueness can be mitigated by vendors as well - MSSSQL allows hints to force desired behavior - but that doesn't so much drop down in abstraction level as it bastardizes the existing one.
bartl 17y ago
>but there are plenty of valid reasons to dislike it The reason why I don't like SQL much, is not because of SQL itself, but because of its poor fit into the host programming language. In PL-SQL, Oracle's own programming language, the SQL statements are simply part of the program. That is how it should be. But in other languages (like Perl), the SQL is like code you need to `eval` at runtime. There is no syntax check until you actually run it. And that makes it cumbersome to work with. Plus, you often have to do optimizations (like to separate `prepare` from the rest of the code) by hand, which only makes it worse. It's all just very low level.