3 ms·

I completely agree with both the title of this post and your comment. The solution is in diagrammatic "languages"/tools like Airflow, not more query languages.

I completely agree with both the title of this post and your comment. The solution is in diagrammatic "languages"/tools like Airflow, not more query languages. Selecting columns before tables always felt weird to me. Doesn't it make more sense if you had a graphical view this way? (imagine boxes around the below items where you can drag lines to make connections between tables/inputs) USERS --user_id-- [data processing] => ... GROUPS In SQL that would be, SELECT * ,groups.* from users INNER JOIN groups ON users.user_id = groups.user_id SQL is so messy and full of details that can be much better represented via dataflow diagrams.

83457 6y ago
There are graphical query generators in at least Microsoft's management tools. Most devs use straight SQL as far as I know because once you get into more complex queries the graphical interface becomes a hassle.
- unityByFreedom 6y ago
  > There are graphical query generators in at least Microsoft's management tools The dev still needs to type the code first, which does not address any problems with SQL. > Most devs use straight SQL as far as I know because once you get into more complex queries the graphical interface becomes a hassle. Those interfaces may be limited, or the devs may not have enough experience writing "code" via a higher-level graphical interface. Going from writing SQL to creating dataflow diagrams may be a bit like switching from imperative to functional programming.
tsimionescu 6y ago
Given our source control tools' limitations, I will take a textual format over graphical representation any day. Either way, queries need to be composed at runtime a lot of the time, so for many uses of SQL you can't just have the queries as blobs that you prepare ahead of time in some other tool - they must be objects you can work with programmatically.
- cafard 6y ago
  Somebody at work just stepped a Microsoft Dynamics "integration". The network admin is trying to recover the integration database from a snapshot. An integration maps data from external files into accounting structures: it uses a GUI, with names that make sense to accountants. And the database that holds it is an Access database with the integration details in a BLOB. I'd pay money for a tool to save these out to a textual representation we could put under source control.
  - unityByFreedom 6y ago
    There's no reason a diagram can't be in source control. You just need a tool that can convert the diagram to code and the code to a diagram. You probably also want to store the diagram's layout in textual form too so it can be converted back to the original human-created layout. Then you can use git and optionally build custom tools like a visual diff of diagram v1 vs v2.
    - tsimionescu 6y ago
      The diff tool is the key here. Without that, there is no meaningful version control.
      - unityByFreedom 6y ago
        With a visual representation, diffing may be as easy as clicking next/previous between versions as you would images in an album. You could of course add more bells and whistles with highlighting.
        tsimionescu 6y ago
        Sorry, I should have been more specific. When I say diffing tool, I mean one that can do what diff does - help Git do automatic merges, and help me do manual merges when auto merge finds conflicts. Two pictures side by side can do neither.
cmrdporcupine 6y ago
"Selection" in the relational algebra is actually everything that comes after the WHERE clause. SQL confuses people here because "SELECT" seems to imply "select these columns" when in fact that is technically called "projection." The "Selection" is the set of predicates that restrict the resulting relation. Projection is choosing which tuples ("columns") to use in it. The relational algebra has no "tables", this is, again, a SQL thing. It has relations (sets of sets) and operations on them. In SQL "tables" are one kind of relation, and views are another.

83457 6y ago

There are graphical query generators in at least Microsoft's management tools. Most devs use straight SQL as far as I know because once you get into more complex queries the graphical interface becomes a hassle.

unityByFreedom 6y ago
> There are graphical query generators in at least Microsoft's management tools The dev still needs to type the code first, which does not address any problems with SQL. > Most devs use straight SQL as far as I know because once you get into more complex queries the graphical interface becomes a hassle. Those interfaces may be limited, or the devs may not have enough experience writing "code" via a higher-level graphical interface. Going from writing SQL to creating dataflow diagrams may be a bit like switching from imperative to functional programming.

tsimionescu 6y ago

Given our source control tools' limitations, I will take a textual format over graphical representation any day. Either way, queries need to be composed at runtime a lot of the time, so for many uses of SQL you can't just have the queries as blobs that you prepare ahead of time in some other tool - they must be objects you can work with programmatically.

cafard 6y ago
Somebody at work just stepped a Microsoft Dynamics "integration". The network admin is trying to recover the integration database from a snapshot. An integration maps data from external files into accounting structures: it uses a GUI, with names that make sense to accountants. And the database that holds it is an Access database with the integration details in a BLOB. I'd pay money for a tool to save these out to a textual representation we could put under source control.
- unityByFreedom 6y ago
  There's no reason a diagram can't be in source control. You just need a tool that can convert the diagram to code and the code to a diagram. You probably also want to store the diagram's layout in textual form too so it can be converted back to the original human-created layout. Then you can use git and optionally build custom tools like a visual diff of diagram v1 vs v2.
  - tsimionescu 6y ago
    The diff tool is the key here. Without that, there is no meaningful version control.
    - unityByFreedom 6y ago
      With a visual representation, diffing may be as easy as clicking next/previous between versions as you would images in an album. You could of course add more bells and whistles with highlighting.
      - tsimionescu 6y ago
        Sorry, I should have been more specific. When I say diffing tool, I mean one that can do what diff does - help Git do automatic merges, and help me do manual merges when auto merge finds conflicts. Two pictures side by side can do neither.

cmrdporcupine 6y ago

"Selection" in the relational algebra is actually everything that comes after the WHERE clause. SQL confuses people here because "SELECT" seems to imply "select these columns" when in fact that is technically called "projection." The "Selection" is the set of predicates that restrict the resulting relation. Projection is choosing which tuples ("columns") to use in it. The relational algebra has no "tables", this is, again, a SQL thing. It has relations (sets of sets) and operations on them. In SQL "tables" are one kind of relation, and views are another.