4 ms·
Sorry, it is wrong. SQL is not baſed on ſets, but bags, which are quite different and more complicated. And, by the way, CTEs are a feature of ISO SQL, not on
by leandrod 17y ago
Sorry, it is wrong. SQL is not baſed on ſets, but bags, which are quite different and more complicated. And, by the way, CTEs are a feature of ISO SQL, not only of MS SQL Server.
Finally, entity‐relationſhip is not terribly practical as a model, but as diagrammiŋ.
- jacobolus 17y ago(It’s off-topic, but why the long esses and engs? The latter are not letters in English, and the former haven’t really been used in at least a century.)
- pradocchia 17y agoThis is true, SQL does not require everything to be a set, strictly speaking, but internally many platforms append a unique row identifier to bags, so that they can be processed as sets. I often wish platforms would expose their internal calculus in a separate syntax, so we wouldn't have to work through the SQL translation layer. Algebraic operators would be nice too.
- leandrod 17y agoÐat may be true, but what platforms do internally ſhould not affect ðeir flavours of SQL. In oðer words, internal implementation as ſets do not make SQL ſet‐baſed.
- pradocchia 17y agoNo argument there (ðere?), SQL is an unfortunate language.
- cturner 17y agoDo you have any thoughts about why there has been no challenge to the SQL syntax? We can easily imagine notations based on relational algebra and relational calculus emerging that could be interpreted at the same levels of an RDBMS as SQL, yet I've not seen anyone attempt it. A good PhD topic for someone?
- encoderer 17y agoSQL was designed to make data accessible to non-programmers. That's why it lacks more advanced/obscure syntax. And the reason why it's stuck is the same story that you can tell over and over about standards.
- shaunxcode 17y agoAPL? (seriously)