3 ms·
SQL is extremely expressive, it's almost impossible to build something that cannot be expressed in an SQL query. In most cases when people feel like SQL cannot
by zaarn 7y ago
SQL is extremely expressive, it's almost impossible to build something that cannot be expressed in an SQL query. In most cases when people feel like SQL cannot do something it is either because the Database does not implement a part of the standard or because they are not familiar with some of the more advanced usage of SQL. Simple SELECT FROM WHERE clauses, even including JOIN, are still fairly simple compared with what you CAN do if you want.
I'd recommend reading the PGSQL manual, they go very in depth about many of the supported features and how they are implement and can be used.
- perl4ever 7y ago"SQL is extremely expressive, it's almost impossible to build something that cannot be expressed in an SQL query." That's kind of orthogonal to what I think is the issue being expressed here. SQL can do many things; the problems tend to be when a query doesn't perform consistently and predictably. There's always a balance to be struck between communicating what is to be done, and how it is to be done, and SQL leaves so much of the "how" out that the query interpreter/optimizer is incredibly sophisticated and does a fantastic amount of work and yet frequently gets things spectacularly wrong, maybe due to misconfiguration and maybe due to fundamental limitations. Obviously more information on how to do something is not always better; otherwise we'd be using assembler. But there is a balance. Experts tend to say "write everything in one query, and if it doesn't work, fix the configuration of your database" which is not helpful given the division of responsibilities in any company. But they will say that because they are devoted to the idea that all that expressiveness is good for something.
- mr_toad 7y ago> SQL is extremely expressive, it's almost impossible to build something that cannot be expressed in an SQL query. If that were true, people would build RDBMS’s in SQL.
- zaarn 7y agoMost of a RDBMS is actually build using SQL. (For example, in PG constraints and foreign keys are done using triggers and SQL Functions.)
- GenericsMotors 7y agoSQL isn't a general purpose language, it's a data query language. It fulfils its purpose and does it well.
- weberc2 7y agoThat's only true tautologically--i.e., if you decide to constrain "its purpose" to the set of things SQL does well. If you want to do something perfectly reasonable--like programmatically building queries to access data of arbitrary (read "unknown at compile time") schema, you'll find it's quite hard to do this, at least if you care about performance at all. Largely because SQL doesn't compose well.
- GenericsMotors 7y agoOptimization requires knowing the schema, and query usage patterns, and data stats - which competent RDBMS engines use to great effect already. Sounds like you're looking for a magic silver bullet - there's no free lunch in our field though. Lastly, the comment I was replying to can be paraphrased as "well is SQL is so great why aren't RDBMS' built using SQL, huh?". Which is a ridiculous question since SQL isn't the right tool for that job - its very name tells you that. If you want to continue arguing against strawmen do it with someone else.
- ErwinSmout 7y agoNot true. Since the addition of SQL/PSM (1996 IIRC) it has become a computationally complete language (procedural like many of the others) with variables and loops and what have you.