3 ms·

Reading this gave me a weird idea. What if SQL is so successful exactly because its syntax makes JOIN operations cumbersome. Other languages where joins are syn

by j-pb 2y ago

Reading this gave me a weird idea. What if SQL is so successful exactly because its syntax makes JOIN operations cumbersome. Other languages where joins are syntactically convenient (e.g. datalog) make it much easier to write slow queries, whereas SQL forces you to denormalise tables tables from a syntactical standpoint already, which later translates to performance gains when it comes to semantics. In a sense SQL is the (typewriter) QWERTY of query languages. Inconvenient by design.

danolivo 2y ago
For me, the key idea of this paper was that relational model & SQL are successful because of the key feature: 'compact and accessible form' of a query.
hipadev23 2y ago
join purchase using (customer_id) They only get cumbersome when you have schemas without consistent key names, complex join conditions, insist on uppercasing reserved words, or do all sorts of formatting acrobatics. So I guess I agree with you. A well designed schema makes reading and writing SQL a pleasure
- rbanffy 2y ago
  > insist on uppercasing reserved words, It makes code a lot more readable
  - williamdclt 2y ago
    As someone who does uppercase SQL, I’m not really convinced it improves readability. We don’t do it for other languages after all, syntax coloration is deemed enough. (On the other hand, sql is often embedded in other languages where it might not get properly coloured so… maybe)
    - rbanffy 2y ago
      Not all languages allow it, and most sexy languages forbid it by being case sensitive with their keywords. I've used this feature in Pascal and Basic and my feeling is that it improves readability a lot, as it better highlights structure than just coloring. OTOH, I've used it mostly on monochrome 1-bit-per-pixel systems where coloring wasn't available. I believe it could be a matter of taste.
- arkh 2y ago
  > customer_id It's hard to fight for those when surrounded by ORM first people. "Why call it customer_id in the customer table, call it id". Because I like using using. "But we don't care we rarely do SQL queries, why optimize for the rare cases?". Enjoy your N+1 ORM only problem then.
  - hipadev23 2y ago
    Yeah exactly. A very different way of thinking. While there are exceptions always (friend table composed of user_id pairs), I view my database/schema as a namespace. So customer_id refers to the same entity across all my tables.
  - euroderf 2y ago
    This one is on the ground floor of my Dept of Pet Peeves.

by j-pb 2y ago

danolivo 2y ago

For me, the key idea of this paper was that relational model & SQL are successful because of the key feature: 'compact and accessible form' of a query.

hipadev23 2y ago

join purchase using (customer_id) They only get cumbersome when you have schemas without consistent key names, complex join conditions, insist on uppercasing reserved words, or do all sorts of formatting acrobatics. So I guess I agree with you. A well designed schema makes reading and writing SQL a pleasure

rbanffy 2y ago
> insist on uppercasing reserved words, It makes code a lot more readable
- williamdclt 2y ago
  As someone who does uppercase SQL, I’m not really convinced it improves readability. We don’t do it for other languages after all, syntax coloration is deemed enough. (On the other hand, sql is often embedded in other languages where it might not get properly coloured so… maybe)
  - rbanffy 2y ago
    Not all languages allow it, and most sexy languages forbid it by being case sensitive with their keywords. I've used this feature in Pascal and Basic and my feeling is that it improves readability a lot, as it better highlights structure than just coloring. OTOH, I've used it mostly on monochrome 1-bit-per-pixel systems where coloring wasn't available. I believe it could be a matter of taste.
arkh 2y ago
> customer_id It's hard to fight for those when surrounded by ORM first people. "Why call it customer_id in the customer table, call it id". Because I like using using. "But we don't care we rarely do SQL queries, why optimize for the rare cases?". Enjoy your N+1 ORM only problem then.
- hipadev23 2y ago
  Yeah exactly. A very different way of thinking. While there are exceptions always (friend table composed of user_id pairs), I view my database/schema as a namespace. So customer_id refers to the same entity across all my tables.
- euroderf 2y ago
  This one is on the ground floor of my Dept of Pet Peeves.