The particular meaning of "better" here was "better at representing the relational model".
If you want to believe that popularity is a measure or reliable indicator of quality, I can't be bothered with you.
PS I have a worked-out example on my site of what it takes to enforce a business rule "no one has a salary higher than his manager's" in SQL (> 100 LOC) and in SIRA_PRISE (one single relatively simple formula of the RA to declare). You decide which is "better".
Much of the comments (and the article) criticize SQL as being non-standard and difficult to learn. These critiques have been around as long as SQL has.
However, there is a more insidious problem with SQL: it's all too easy to write SQL statements that have O(N^2) complexity. A simple JOIN can easily result in O(N^2) complexity, yet there aren't easy tools to identify these performance issues. As a result, as a database grows, things that once were executed quickly take forever.
I'd like to see the end of joins, replaced with something that is more explicit about what is happening under the hood.
but no-one is using them, so are they actually better? (philosphical question, also pertains to a ton of better options... I mourn BeOS)
The particular meaning of "better" here was "better at representing the relational model".
If you want to believe that popularity is a measure or reliable indicator of quality, I can't be bothered with you.
PS I have a worked-out example on my site of what it takes to enforce a business rule "no one has a salary higher than his manager's" in SQL (> 100 LOC) and in SIRA_PRISE (one single relatively simple formula of the RA to declare). You decide which is "better".
Much of the comments (and the article) criticize SQL as being non-standard and difficult to learn. These critiques have been around as long as SQL has.
However, there is a more insidious problem with SQL: it's all too easy to write SQL statements that have O(N^2) complexity. A simple JOIN can easily result in O(N^2) complexity, yet there aren't easy tools to identify these performance issues. As a result, as a database grows, things that once were executed quickly take forever.
I'd like to see the end of joins, replaced with something that is more explicit about what is happening under the hood.
2 replies →