← Back to context

Comment by 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.

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.

  • 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.

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

  • 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