Not necessarily. If you ponder the importance of proper (robust, reliable, dependable) data management for data that keeps nuclear plants going, for farmaceutical research data, for anything happening on the financial…
And Tony Hoare probably wished he hadn't made his "billion dollar mistake". But at any rate, you could also try and ponder how unbelievably exceptionally awful it must have been that existed before SQL if something as…
"The one that his a lot of people is WHERE <value> NOT IN (<set>) where <set> contains a NULL. Because NOT IN unrolls to “<value> <> <s1> AND <value> <> <s2> AND … AND <value> <> <sx>” any NULL values in the set makes…
Yes. The reason is lazy people expect to be able to ask five questions in one go and expect one single answer to answer all five of them. The key is to realize that submitting a query is to ask a question. So how many…
The predicate corresponding to an outer join is fundamentally disjunctive in nature (any outer join is equivalent to a UNION of at least 2 SELECTs) meaning that "after the fact", there is no way to determine which…
"Many of those complaints seem theoretical. I like to focus on practical concerns." The only reason ever why people engage into theory, is precisely because of a deeply rooted desire to address "practical concerns".…
:-) And those that are built on "first principles" end up looking like a dog's breakfast just as well because people expect to not have to learn a novel language. People don't want to be told to forget everything they…
"There were also definitely some bad paradigms invented as a result of SQL (e.g. all business logic lives in the database as stored procedures or stored functions)," I hope you don't mean by that that integrity…
In the relational model, no there is no such thing as "optional values". Even Codd often hinted (quite a bit of material in the 1990 book gives such hints) that "if a row has a null somewhere, it SHOULDN'T BE CONSIDERED…
"NULL only has one meaning: NULL. This is roughly analogous to unknown." From the re-published version of "Much ado about nothing, part 2" (re-published in "Database Dreaming, Vol II) : "An outer join produces nulls…
In "Stating the obvious", C.J. Date wrote 50 (FIFTY) pages solely on the subject of how SQL screwed up with the most fundamental operator of all : testing for equality. I'll repeat : FIFTY pages about everything that…
In fact, Date has recently revised a whole slew of "old" papers of his, got them up-to-date wrt his current thinking, and (re-) published them. His "A critique of SQL/86" paper(s) are now chapter 8, 9 & 10 of "Database…
What they "called out as flawed" was the impossibility to declare any such rule with SQL as it stood. What they were "criticizing" was precisely the fact that a data language that was supposed to be "expressively…
Because "speaking SQL" [even before SQL as such was even invented, hence the scare quotes] was intended as a skill to be practiced only by those who also grasped the [mathematical] logic of what they were doing when…
With one single exception : you cannot use a CHECK clause to check that a table must be nonempty, because the semantics of the CHECK clause are that it must be satisfied by all rows in the table, and therefore the empty…
I invite you to inspect, even if only cursorily, my above exchange with mr. antonvs. My point is that Micro$oft was created by programmers (in fact in its earliest days it was mostly a compilers company), that to this…
No, Date did not "miss the point". He properly identified that all of Meijer's arguments he used to make his point were in fact complete bunk. And he clearly and factually answered why that was so, on a blow-by-blow…
Dude, please, give me a break. Erik Meijer is that, eurhm, person, I remember from publicly stating that his favourite resarch method is "throwing things at the wall and see what sticks". WOW. That's the way of the true…
The basic text of the book was written before Lex died (must have been +- 2006), my work in which I cracked that problem saw the light of day after that time. So "we do not yet know ..." was technically correct at the…
It was probably also influenced by Codd's own preference for the data language in calculus-based style (Codd's roots as a mathematician are to "blame" here), as opposed to algebra-based (the style typically preferred by…
"And yet an API is kinda desirable." Yeah. however I may not live to see the day when that desire, which I agree is felt by 99.99% of the developer community (hell, even by 99.99% of the end user community because don't…
In the perception of the Micro$oft users who are brainwashed with the idea that what Micro$oft does is good for the developers. (In fact, it might even be outright true. But that's not a guarantee that what the…
Link between me and SIRA_PRISE : I am the author. codeshitter ad-homs : yeah well I know they are. The fact of the matter is the history between SIRA_PRISE and me (and why I did it in the first place) is now almost 20…
See the "business case for SIRA_PRISE". Imagine how many years of codeshitter-hours you [or, if you're in the DBMS market, your customers] would no longer have to pay for if you could have *ALL* of your [strictly…
I doubt that it does. There is way more to "integrating [host] language and queries" than the MIN() of what Micro$oft engineers are (a) capable of understanding and (b) allowed by their own management to put in the…
Not necessarily. If you ponder the importance of proper (robust, reliable, dependable) data management for data that keeps nuclear plants going, for farmaceutical research data, for anything happening on the financial…
And Tony Hoare probably wished he hadn't made his "billion dollar mistake". But at any rate, you could also try and ponder how unbelievably exceptionally awful it must have been that existed before SQL if something as…
"The one that his a lot of people is WHERE <value> NOT IN (<set>) where <set> contains a NULL. Because NOT IN unrolls to “<value> <> <s1> AND <value> <> <s2> AND … AND <value> <> <sx>” any NULL values in the set makes…
Yes. The reason is lazy people expect to be able to ask five questions in one go and expect one single answer to answer all five of them. The key is to realize that submitting a query is to ask a question. So how many…
The predicate corresponding to an outer join is fundamentally disjunctive in nature (any outer join is equivalent to a UNION of at least 2 SELECTs) meaning that "after the fact", there is no way to determine which…
"Many of those complaints seem theoretical. I like to focus on practical concerns." The only reason ever why people engage into theory, is precisely because of a deeply rooted desire to address "practical concerns".…
:-) And those that are built on "first principles" end up looking like a dog's breakfast just as well because people expect to not have to learn a novel language. People don't want to be told to forget everything they…
"There were also definitely some bad paradigms invented as a result of SQL (e.g. all business logic lives in the database as stored procedures or stored functions)," I hope you don't mean by that that integrity…
In the relational model, no there is no such thing as "optional values". Even Codd often hinted (quite a bit of material in the 1990 book gives such hints) that "if a row has a null somewhere, it SHOULDN'T BE CONSIDERED…
"NULL only has one meaning: NULL. This is roughly analogous to unknown." From the re-published version of "Much ado about nothing, part 2" (re-published in "Database Dreaming, Vol II) : "An outer join produces nulls…
In "Stating the obvious", C.J. Date wrote 50 (FIFTY) pages solely on the subject of how SQL screwed up with the most fundamental operator of all : testing for equality. I'll repeat : FIFTY pages about everything that…
In fact, Date has recently revised a whole slew of "old" papers of his, got them up-to-date wrt his current thinking, and (re-) published them. His "A critique of SQL/86" paper(s) are now chapter 8, 9 & 10 of "Database…
What they "called out as flawed" was the impossibility to declare any such rule with SQL as it stood. What they were "criticizing" was precisely the fact that a data language that was supposed to be "expressively…
Because "speaking SQL" [even before SQL as such was even invented, hence the scare quotes] was intended as a skill to be practiced only by those who also grasped the [mathematical] logic of what they were doing when…
With one single exception : you cannot use a CHECK clause to check that a table must be nonempty, because the semantics of the CHECK clause are that it must be satisfied by all rows in the table, and therefore the empty…
I invite you to inspect, even if only cursorily, my above exchange with mr. antonvs. My point is that Micro$oft was created by programmers (in fact in its earliest days it was mostly a compilers company), that to this…
No, Date did not "miss the point". He properly identified that all of Meijer's arguments he used to make his point were in fact complete bunk. And he clearly and factually answered why that was so, on a blow-by-blow…
Dude, please, give me a break. Erik Meijer is that, eurhm, person, I remember from publicly stating that his favourite resarch method is "throwing things at the wall and see what sticks". WOW. That's the way of the true…
The basic text of the book was written before Lex died (must have been +- 2006), my work in which I cracked that problem saw the light of day after that time. So "we do not yet know ..." was technically correct at the…
It was probably also influenced by Codd's own preference for the data language in calculus-based style (Codd's roots as a mathematician are to "blame" here), as opposed to algebra-based (the style typically preferred by…
"And yet an API is kinda desirable." Yeah. however I may not live to see the day when that desire, which I agree is felt by 99.99% of the developer community (hell, even by 99.99% of the end user community because don't…
In the perception of the Micro$oft users who are brainwashed with the idea that what Micro$oft does is good for the developers. (In fact, it might even be outright true. But that's not a guarantee that what the…
Link between me and SIRA_PRISE : I am the author. codeshitter ad-homs : yeah well I know they are. The fact of the matter is the history between SIRA_PRISE and me (and why I did it in the first place) is now almost 20…
See the "business case for SIRA_PRISE". Imagine how many years of codeshitter-hours you [or, if you're in the DBMS market, your customers] would no longer have to pay for if you could have *ALL* of your [strictly…
I doubt that it does. There is way more to "integrating [host] language and queries" than the MIN() of what Micro$oft engineers are (a) capable of understanding and (b) allowed by their own management to put in the…