"The Programmer As Navigator"
Quote from Erwin on February 14, 2020, 7:54 amQuote from dandl on February 13, 2020, 11:52 pmIt is, after all, part of the reason for the success of SQL, despite not being an implementation of the relational model.
I will argue that SQL offers a superset of the RM. At least, I don't know anything the RM/RA can do that SQL can't, although it certainly takes discipline to toe the line.
And a high level of tolerance toward baroque language design and utterly incomprehensible restrictions (see the askew wall for some examples, particularly the "cities with more than 4 inhabitants" one, which IIRC is the very one that gave birth to TTM).
As for "anything the RM/RA can do that SQL can't" : anything that actually requires the scalar type system to be truly open-ended (which SQL does not have, and never will). The "comparative survey" book has a quite in-depth discussion of how SQL has several distinct attempts to reach the mark, but never quite succeeds. Oh, and RVA's in base tables of course. And testing table equality.
Quote from dandl on February 13, 2020, 11:52 pmIt is, after all, part of the reason for the success of SQL, despite not being an implementation of the relational model.
I will argue that SQL offers a superset of the RM. At least, I don't know anything the RM/RA can do that SQL can't, although it certainly takes discipline to toe the line.
And a high level of tolerance toward baroque language design and utterly incomprehensible restrictions (see the askew wall for some examples, particularly the "cities with more than 4 inhabitants" one, which IIRC is the very one that gave birth to TTM).
As for "anything the RM/RA can do that SQL can't" : anything that actually requires the scalar type system to be truly open-ended (which SQL does not have, and never will). The "comparative survey" book has a quite in-depth discussion of how SQL has several distinct attempts to reach the mark, but never quite succeeds. Oh, and RVA's in base tables of course. And testing table equality.
Quote from dandl on February 14, 2020, 9:30 amI readily agree that the SQL type system is inferior, but since the RM/RA doesn't have one that's not really a distinguishing feature. Yes, we have to jump through serious hoops to get SQL to deal with quite ordinary data types, especially for RVAs, but the type system is not the RM/RA.
SQL really cannot represent DUM and DEE. It has no direct support for antijoin (semiminus/not matching) and solutions to that one get all bound up in null handling. It has no relational equals, subset etc but in each case it has just enough primitives to get there (always hoping the optimiser does something reasonable).
The version of Andl that emits SQL passes all the tests (except for recursion and windowing, which were just too hard).
There is a spectrum between pure and useful, and my sweet spot is heavily influenced by the idea of being able to get stuff done.
I readily agree that the SQL type system is inferior, but since the RM/RA doesn't have one that's not really a distinguishing feature. Yes, we have to jump through serious hoops to get SQL to deal with quite ordinary data types, especially for RVAs, but the type system is not the RM/RA.
SQL really cannot represent DUM and DEE. It has no direct support for antijoin (semiminus/not matching) and solutions to that one get all bound up in null handling. It has no relational equals, subset etc but in each case it has just enough primitives to get there (always hoping the optimiser does something reasonable).
The version of Andl that emits SQL passes all the tests (except for recursion and windowing, which were just too hard).
There is a spectrum between pure and useful, and my sweet spot is heavily influenced by the idea of being able to get stuff done.
Quote from Dave Voorhis on February 14, 2020, 9:36 amQuote from dandl on February 13, 2020, 11:52 pmI'm not arguing with the RM/RA or the core concept of TTM. I'm just pointing to a specific limitation that arises from the unification in D of the type system with column names and of relvar assignment with database update. Different choices here and in a few other areas like natural join, aggregation, recursion could produce something different. Just tweaking TTM is probably not enough.
Indeed. Design it. Build it. Explore the implications. Identify the pros and cons.
Quote from dandl on February 13, 2020, 11:52 pmI'm not arguing with the RM/RA or the core concept of TTM. I'm just pointing to a specific limitation that arises from the unification in D of the type system with column names and of relvar assignment with database update. Different choices here and in a few other areas like natural join, aggregation, recursion could produce something different. Just tweaking TTM is probably not enough.
Indeed. Design it. Build it. Explore the implications. Identify the pros and cons.