← Back to context

Comment by bachmeier

4 years ago

My thought is that joins are the tough part of the SQL learning curve, but I don't see much in here that reduces the complexity of joins.

7 comments

bachmeier

Reply
omarhaneef  4 years ago

There was this professor of language who would say "Do you think the question ('are carpets furniture?') tells you something about the ambiguity of the word carpet, or do you think it tells you something about the ambiguity in the world?"

Similarly, I think joins are "tough" not because of the way SQL expresses them but because the logical possibilities of merging data from multiple tables are varied.

  • bob1029  4 years ago

    There is no such thing as a domain-agnostic SQL database that holds up under this kind of semantic scrutiny. I don't think that there ever could be.

    If you are rolling a SQL schema for a home improvement contractor, it is extraordinarily unlikely that their specific business would expect any scenarios in which carpets are sometimes known as furniture.

    Having a bounded context to operate within is what makes SQL magical for me. When people don't understand the business or simply the game around how you talk about the business, things start getting messy wrt joins.

    • omarhaneef  4 years ago

      The carpet discussion was simply to say that you can't take out all the complexity of a language if the domain it is meant to describe is complex. The language has a limit to how simple it can be.

      I was not proposing a SQL database of carpets, or furniture, as a thought experiment.

  • bachmeier  4 years ago

    Then make some cases easier and fall back to the SQL we already have for the rest?

    • Supermancho  4 years ago

      SQL has effectively failed, as a standard, despite it's ubiquity. It's literally being aged out, which makes for opportunities for PRQL, etc to fill pragmatic gaps.

      eg the lack of default column aliasing from joins

          SELECT 
        A.id AS A__id, 
        A.name AS A__name, 
        B.id AS B__id, 
        B.name AS B__name 
    FROM A 
    LEFT JOIN B 
        ON A.other_id = B.other_id

      When you could have:

          SELECT 
        A.*, 
        B.* 
    FORMAT (TABLE__) 
    FROM A 
    LEFT JOIN B 
        ON A.other_id = B.other_id

cogman10  4 years ago

IMO, this appears not to be something that solves the SQL learning curve but rather the usability of a query language with tooling.

I don't think there is much that could be done to address left, right, inner, outer join semantics. It's just something you have to learn if you want to do a lot of SQL (though, you are likely only ever going to use left and inner joins).