4 ms·

If only SQL was designed to be written in the order of execution: FROM user WHERE last_name = $lastName SELECT id, first_name

cmrdporcupine 4y ago
"SELECT" doesn't mean what you think it means, I think. In the relational algebra "select" is actually a "filter" operation. It's what the "where clause" implies. The other name for it is "Restrict." It reduces the result set down to the tuples that match on the supplied predicates. SQL does a funny thing by putting it at the front of the query, but it does so as a way of saying "Hey, I'm about to begin a relational query." What you've done here is more incorrect. Maybe? Not sure of your intent. The name for the operator which "chooses which attributes to put in my results" is "PROJECTION". That's the thing that some people seem to think "select" refers to. In a more pure relational system it would look something like (syntax totally made up) Project( (id, first_name), Select( Predicate(last_name = $lastName), Relation(User))) Or maybe: User.Select(last_name=$lastName).Project({id, first_name}) As for this "order of execution" thing, SQL explicitly doesn't do that on purpose because the entire point is that the query optimizer can and should re-order things for the most efficient result. The beauty of the relational algebra (which SQL only partially implements) is that the order of operations can in many cases be re-ordered (in logically provable ways). So there is no set execution order. The system can take care of that for you.
- karamanolev 4y ago
  Without any further knowledge, what I think they did is not so much express execution order in the RDBMS engine sense, but some logical generic-to-specific, large-to-small order. Table first (all rows, all columns), WHERE after (filter row), SELECT/project (filter columns). I'm not sure where all the other SQL operators would fit in that order, especially JOINs, GROUP BYs and so on.
  - cmrdporcupine 4y ago
    Yeah I guess the thing is that that 'logical' ordering is entirely arbitrary. It makes sense to this author I guess, but wouldn't to others. SQL's syntax is crap, but I don't see any advantages to this. Chris Date's Tutorial D had alternate syntax proposals. Personally I'd go for something more terse, like in the Rel Project's impl of the D concepts: USER {ID, FIRST_NAME} WHERE LAST_NAME= NAME($lastName) https://reldb.org/c/wp-content/uploads/2017/12/Rel-and-Tutorial-D-Quickstart.pdf https://reldb.org/c/wp-content/uploads/2017/12/Rel-and-Tutor...
  - deleted 4y ago
    [deleted]
- twic 4y ago
  SQL's SELECT does both restriction and projection; indeed, it always does projection, but the restriction is optional: select id, first_name from user; So it's not crazy to equate SELECT with projection. If we're making up new syntaxes for relational calculus, i think something pipey would feel most natural: from user | restrict last_name = $last_name | project id, first_name; Letting you repeat stages as you see fit (this is somewhat silly example): from user | project *, is_boss = role in ('manager', 'executive') | restrict last_name = $last_name and is_boss | project id, first_name; You need some sort of converging fork to do joins, maybe: from user | restrict role = 'executive' > boss from department | restrict location = 'HQ' > hq_dept join < boss < hq_dept on boss.id = hq_dept.head_id | project first_name, last_name, dept_name Or maybe something better!
  - madeofpalk 4y ago
    Did you just accidentally invent KQL? https://docs.microsoft.com/en-us/azure/data-explorer/kusto/query/ https://docs.microsoft.com/en-us/azure/data-explorer/kusto/q...
    - twic 4y ago
      Oh, I'm going to sue these bozos into the ground.
  - cmrdporcupine 4y ago
    I like it. Let's implement it.
dspillett 4y ago
This is a common complaint, but I've never felt the normal arrangement to be counter-intuitive. I read it as “I want the id and first name, you can get this from…” — the projection clause stating what you want, and the following clauses detailing how the information what you want can be found in is arranged. You can also think of it like a recipe: “I'm, going to make a cake, from eggs, flour, …” rather than following the instructions then at the end being told what you are making. While “from <here>, filtering by <condition>, pick <things>” better matches your view of what the database engine is going to do to service your request, matching what the engine does internally to service your request is not SQL's priority. As another example of this: with joins you are not telling the engine “this is how to do…” (well, you are, but indirectly) — what you are actually doing is describing how the information links together. With this information and other information it already has (from the schema, particularly what indexes are available) it will decide the best way to proceed, and in fact will sometimes effectively reorder your request for efficiency (some simple DB engines will always follow the order you state the objects to use, but that is their limitation not something dictated by SQL in theory).
8organicbits 4y ago
I like that order, it matches how I'd work with a Javascript list of objects: users.filter((u) => u.lastName == "foo").map((u) => [u.id, u.firstName]); Python looks like the original SQL if you do it as a list comprehension: [ (user.id, user.firstName) for user in users if user.lastName == "foo" ]
julienfr112 4y ago
as a declarative language, SQL does not expose the order of execution to the user.
- politician 4y ago
  > as a declarative language, SQL does not expose the order of execution to the user. As a practical matter, this is not true. If it were true, tools like EXPLAIN PLAN would not exist because it would not be necessary to manipulate queries to get good performance.

cmrdporcupine 4y ago

"SELECT" doesn't mean what you think it means, I think. In the relational algebra "select" is actually a "filter" operation. It's what the "where clause" implies. The other name for it is "Restrict." It reduces the result set down to the tuples that match on the supplied predicates. SQL does a funny thing by putting it at the front of the query, but it does so as a way of saying "Hey, I'm about to begin a relational query." What you've done here is more incorrect. Maybe? Not sure of your intent. The name for the operator which "chooses which attributes to put in my results" is "PROJECTION". That's the thing that some people seem to think "select" refers to. In a more pure relational system it would look something like (syntax totally made up) Project( (id, first_name), Select( Predicate(last_name = $lastName), Relation(User))) Or maybe: User.Select(last_name=$lastName).Project({id, first_name}) As for this "order of execution" thing, SQL explicitly doesn't do that on purpose because the entire point is that the query optimizer can and should re-order things for the most efficient result. The beauty of the relational algebra (which SQL only partially implements) is that the order of operations can in many cases be re-ordered (in logically provable ways). So there is no set execution order. The system can take care of that for you.

karamanolev 4y ago
Without any further knowledge, what I think they did is not so much express execution order in the RDBMS engine sense, but some logical generic-to-specific, large-to-small order. Table first (all rows, all columns), WHERE after (filter row), SELECT/project (filter columns). I'm not sure where all the other SQL operators would fit in that order, especially JOINs, GROUP BYs and so on.
- cmrdporcupine 4y ago
  Yeah I guess the thing is that that 'logical' ordering is entirely arbitrary. It makes sense to this author I guess, but wouldn't to others. SQL's syntax is crap, but I don't see any advantages to this. Chris Date's Tutorial D had alternate syntax proposals. Personally I'd go for something more terse, like in the Rel Project's impl of the D concepts: USER {ID, FIRST_NAME} WHERE LAST_NAME= NAME($lastName) https://reldb.org/c/wp-content/uploads/2017/12/Rel-and-Tutorial-D-Quickstart.pdf https://reldb.org/c/wp-content/uploads/2017/12/Rel-and-Tutor...
- deleted 4y ago
  [deleted]
twic 4y ago
SQL's SELECT does both restriction and projection; indeed, it always does projection, but the restriction is optional: select id, first_name from user; So it's not crazy to equate SELECT with projection. If we're making up new syntaxes for relational calculus, i think something pipey would feel most natural: from user | restrict last_name = $last_name | project id, first_name; Letting you repeat stages as you see fit (this is somewhat silly example): from user | project *, is_boss = role in ('manager', 'executive') | restrict last_name = $last_name and is_boss | project id, first_name; You need some sort of converging fork to do joins, maybe: from user | restrict role = 'executive' > boss from department | restrict location = 'HQ' > hq_dept join < boss < hq_dept on boss.id = hq_dept.head_id | project first_name, last_name, dept_name Or maybe something better!
- madeofpalk 4y ago
  Did you just accidentally invent KQL? https://docs.microsoft.com/en-us/azure/data-explorer/kusto/query/ https://docs.microsoft.com/en-us/azure/data-explorer/kusto/q...
  - twic 4y ago
    Oh, I'm going to sue these bozos into the ground.
- cmrdporcupine 4y ago
  I like it. Let's implement it.

dspillett 4y ago

This is a common complaint, but I've never felt the normal arrangement to be counter-intuitive. I read it as “I want the id and first name, you can get this from…” — the projection clause stating what you want, and the following clauses detailing how the information what you want can be found in is arranged. You can also think of it like a recipe: “I'm, going to make a cake, from eggs, flour, …” rather than following the instructions then at the end being told what you are making. While “from <here>, filtering by <condition>, pick <things>” better matches your view of what the database engine is going to do to service your request, matching what the engine does internally to service your request is not SQL's priority. As another example of this: with joins you are not telling the engine “this is how to do…” (well, you are, but indirectly) — what you are actually doing is describing how the information links together. With this information and other information it already has (from the schema, particularly what indexes are available) it will decide the best way to proceed, and in fact will sometimes effectively reorder your request for efficiency (some simple DB engines will always follow the order you state the objects to use, but that is their limitation not something dictated by SQL in theory).

8organicbits 4y ago

I like that order, it matches how I'd work with a Javascript list of objects: users.filter((u) => u.lastName == "foo").map((u) => [u.id, u.firstName]); Python looks like the original SQL if you do it as a list comprehension: [ (user.id, user.firstName) for user in users if user.lastName == "foo" ]

julienfr112 4y ago

as a declarative language, SQL does not expose the order of execution to the user.

politician 4y ago
> as a declarative language, SQL does not expose the order of execution to the user. As a practical matter, this is not true. If it were true, tools like EXPLAIN PLAN would not exist because it would not be necessary to manipulate queries to get good performance.