3 ms·

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 car

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 5y 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 5y 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.
- eurasiantiger 5y ago
  EdgeDB
bachmeier 5y ago
Then make some cases easier and fall back to the SQL we already have for the rest?
- Supermancho 5y 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

bob1029 5y 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 5y 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.
eurasiantiger 5y ago
EdgeDB

bachmeier 5y ago

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

Supermancho 5y 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