SQL:2023 says SQL is “pseudo-relational” instead of truly relational.
Quote from AntC on March 27, 2025, 5:37 am[**] ISO is extraordinarily closely-guarded. I've been down a lot of rabbit-holes claiming to show me older copies of ISO-9075 Part 1, but they keep leading to the 2023 wording, or wanting to charge big bucks. This appears to be a draft 1992 standard, but beware the caveats at the top of the doco. "Pseudo-" anything doesn't appear. Indeed the doco neither asks nor answers "What is SQL?" Neither "relational" nor "relation" appears. "Model" appears only as in "data model" of some example schemas, not 'XXX model of data'. "Codd" doesn't appear.
Marcus Winand has a good page on the SQL Standard - https://modern-sql.com/standard - but generally you can't get a copy (AFAIK) of anything other than that 1992 draft without paying good money.
ChatGPT says:
The International Organization for Standardization (ISO) charges for most of its standards because it operates as a non-governmental organization that relies on revenue from standard sales, memberships, and licensing to fund its work.
However, ISO does provide some standards for free, often when they are considered highly beneficial to public safety, innovation, or global trade.
So, I guess SQL does not meet that last criteria!
Complaints about the non-free status of the SQL Standard can be found, e.g. https://news.ycombinator.com/item?id=35567708
Quote from Paul Vernon on March 26, 2025, 11:57 am
Are those words new in the 2023 version, or were they there before?
I'm minded to think that these words are new in the 2023 version. Certainly the "What is SQL" section was not in the Table of Contents on the 2016 Part 1 - Framework. I believe that historically, the word "relational" has been almost completely absent from the SQL standard documents in general.
Also do we know who proposed those words to be added?
The wording certainly make me think of Hugh, but maybe it was Jim Melton (the long time editor of the SQL standard) with some old influence seeping thru
I'm curious why everyone is so concerned about 'The Standard', on two grounds.
One is that as I've experienced it, there isn't one. I've written SQL for SQL Server, MySQL, Postgres and a couple of others. News is: they're different. You write code to what the vendor accepts, no more, no less.
The other is: why here? What possible relevance does that have to anything this forum concerns itself with? And why should it?
Quote from dandl on March 31, 2025, 3:25 amI'm curious why everyone is so concerned about 'The Standard', on two grounds.
One is that as I've experienced it, there isn't one.
What would you call the ANSI/ISO SQL thing then? A formal specification?
And I believe it still qualifies as an aspirational standard at least for SQL vendors, as it is a combination of reflecting current practice as well as inspiring others to follow the same.
It is common that there are regular updates to SQL products specifically to implement stuff in ANSI/ISO SQL.
Quote from dandl on March 31, 2025, 3:25 am... why here? What possible relevance does that have to anything this forum concerns itself with?
The forum/TTM in general concerns itself with the 'Truly Relational Model'; and encounters mostly indifference in the industry. Many programmers think SQL is Relational/indeed many introductory courses and texts say as much; what's the drama? So now we can point to the ISO's very own document to disabuse them.
Fair enough. But what problem should we be trying to solve? I can point to very specific benefits in adopting an ERA, type system and database language of the kind I've outlined, but are they enough? After all, Excel, Word, Outlook and PowerPoint have plenty of faults, but their competitors cannot win on Windows home turf. It was the Web that created Gmail.
So the question is: what future problem will need a database solution that is not SQL? And will the RM have a role to play then, or has it done its dash?
Quote from dandl on March 31, 2025, 11:38 amFair enough. But what problem should we be trying to solve? I can point to very specific benefits in adopting an ERA, type system and database language of the kind I've outlined, but are they enough?
If you can point out how "an ERA, type system and database language of the kind I've outlined" makes companies using it (for what is currently a very undefined value of "it") consistently more profitable and/or their goods/services more saleable, you may be onto something.
Mere technical benefit -- easier/faster to code, more provable, etc. -- are a nearly impossible sell against conventional toolchains, even for established, well-supported products.
So the question is: what future problem will need a database solution that is not SQL? And will the RM have a role to play then, or has it done its dash?
As I've argued before, there may be a place for the relational model in areas that aren't databases at all, but against the mainstream SQL-plus-popular-general-purpose-language world unless you have something that is truly revolutionary -- like, you can't afford not to use this new thing -- there's little incentive to replace what we've currently got or are getting from the major vendors.
That's especially true from the point of view of the working IT masses, for whom the relational model is either unknown; barely-known obscure theory endured in university; at best barely evolutionary; or what SQL already is.
Though the conceptual essence of the relational model -- a few composable primitives to construct expressions that manipulate simple structures -- is core to modern business programming and a lot of programming in general, but it applies to various constructs and not just relations. Old-skool imperative iterative code and its festival of loops and indices is going away, albeit slowly.