[ [Relational] Database] Open Architecture Standard

[Derek Ignatius Asirvadem]

> On Saturday, 4 July 2020 21:48:32 UTC+10, yanka...@gmail.com wrote:

> Derek

> Could you please explain a bit more the Open Architecture standard from 1984 perfected in 1990 from a non-hardware point of view? (http://www.softwaregems.com.au/Documents/Article/Application%20Architecture/Open%20Architecture.pdf)

This is a substantial subject, so I have opened a new thread.

First, please note, paying customers obtain documents with far more detail. The documents that I have made available to the public are simplified forms, minus configuration details, and minus the content that I deliver in courses. This is a one-page public doc, of a five-page customer doc or about 10 pages of SQL Developer Course content. Nevertheless, I will answer specific questions.

Second, since you are quoting me, allow me to clarify what I meant:

> Open Architecture standard from 1984

Which was known to all professionals at the time. And still is.

But a full 95% of the people who implement systems these dark days are uneducated in the relevant sciences, and unprofessional in their implementation (ie. without standards).

Theoreticians in those days were not interested in Standards, on the basis that it was an implementation concern. Theoreticians and "theoreticians" these days have made that a fortified position. This is so that they can continue generating theory that has no relevance in the practical world, because even the reference to a Standard usually destroys the theory. Eg. You may have noticed that I regularly destroy the anti-Relational theory that the freaks come up with, to fix some fantasised problem, by providing the Relational solution that eliminates said problem (and thus no solution is necessary).

> Open Architecture

The purpose. The term means:
- one and only one database where a particular data element is stored
- that is open
- to being queried by anyone, using any database reporting tool (simple & cheap or complex & expensive)
--- (ie. *not* limited to accessing the data via one or more or a mixture of apps)
- which allows the corporation to enjoy the first and foremost principle of a database: one version of the truth, in one place

The Standard provides such a database, one that is available to all compliant apps, and any report tool. Further it prevents non-compliant apps from their destructive actions.

(Separately, a fully Relational database provides full OLAP, in addition to full OLTP, so the report tool is simple and cheap. Whereas the RFS labelled as "relational", which is heavily promoted by the "theoreticians" in this space, require a massive and expensive OLAP transformation layer, such as BusinessObjects.)

The absence of Open Architecture, is not "closed architecture", a term that is somewhat used to identify the counterpoint, but a Non-Arcjitecture.

> Open Architecture standard

Thus the term has disappeared from use, because everyone these days pretends that their monolith is "architecture", that their non-architecture is "architecture". Those lies start to crumble when one uses specific terms.

Gee, why would anyone want an open database, when everyone is screaming about the hell they have with closed databases, that the "theoreticians" and the uneducated dummies that implement their methods declare that that is the only architecture there is, that that is the only way to build an app.

> perfected in 1990

That is, the details, the standards necessary for the various elements, were either already extant, or extant and then modulated for the context of the Relational Model and an genuine SQL platform.

In those heady days when the first few genuine Relational/SQL platforms came out, the correct method, the correct approach was discussed and easily defined, due to:
a. Codd's Relational Model (the implications that a normal human would determine)
b. Codd's Twelve Rules (famous document at the time, to ensure platform suppliers were supplying genuine Relational capability)
c. existing standards that were well-established in the pre-Relational platforms. Such as OLTP Standards for ACID Transactions (which all SQL-compliant platforms have, and which the fraudulent "sql" providers do NOT have).

----

I doubt that I have answered anything that is relevant to what you are seeking. If you could please as a specific question, maybe quote a term that I use in that condensed document, that you seek exposition for, I would be pleased to provide a specific answer.

> from a non-hardware point of view

Please be more specific.

Cheers
Derek

[edpr...@gmail.com]

I haven't checked in here for a long time. Nice to see
that some one is holding forth on the standard. Keep up the good work.

Ed

[Derek Ignatius Asirvadem]

Thank you
Derek

[Derek Ignatius Asirvadem]

> On Monday, 6 July 2020 20:37:03 UTC+10, Derek Ignatius Asirvadem wrote:
> > On Saturday, 4 July 2020 21:48:32 UTC+10, yanka...@gmail.com wrote:
>
> > Derek
>
> > Could you please explain a bit more the Open Architecture standard from 1984 perfected in 1990 from a non-hardware point of view? (http://www.softwaregems.com.au/Documents/Article/Application%20Architecture/Open%20Architecture.pdf)
>
> This is a substantial subject, so I have opened a new thread.

Here is another increment.

In this larger issue of trying to understand Open Architecture Standards, ie. by the people who need it, and do not understand it, there are several different problems (at least that they exist in different problem-solution subject areas, and thus should be approached quite differently).

The first is the utter stupidity and ignorance of developers who expect to implement a system that contains a database using ONE TOOL. Why ? Because they know only One Tool. Because their entire perspective of the whole universe is limited to this tiny myopic One Tool. Please read
____Maslow's Law of the Instrument 1966,
commonly known as
____Maslow's Hammer.
The idea is, if a developer has a hammer, and knows it quite well, and only knows a hammer (ignorant of an axe; a screwdriver; a plane; etc), then every problem that he is given to solve looks like a nail.

The solution is to teach him (if he is teachable) that although OO and UML /might/ be good for client-side programming; GUIs; etc, it is quite hopeless at defining data correctly. If his perspective of the data is limited to his app, he is crippled, he cannot perceive the data, as data, and nothing but data, independent of any and all apps that may access the data, which is the absolute requirement for data modelling (let alone Relational data modelling).

Second, he is ham-strung in his tool set because UML, his darling modelling tool, is totally inadequate because it is broken, it cannot document (model) composition/decomposition. So his client-side GUI is based on a model that cannot, did not, analyse the requirement, and after that pitiful analysis, he cannot, did not, design a solution from the requirement. UML is not a standard by any measure of a standard, it is merely a broken documentary facility, and for Objects only.

Further on that point, if he uses that pathetic UML to analyse and design the data, to model the data, he is crippled in that arena as well. Since the understanding; analysis; design, of data is based on quite different rules and principles, one must use the Right Tool for the Job: IDEF1X for Relational database modelling, and the rules for data science.

The Right Tool for process modelling (full composition/decomposition) is either SSADM or IDEF0.

Third, he is completely bamboozled by the "theoreticians" who contaminate this science, who market ancient and primitive methods falsely claimed to be "relational". Now this is the large mountain of pig poop that is the de facto standard for "designing" and "implementing" apps in the OO/ORM space.

They are quite happy being clueless about the data (what the data actually is), and thus they are forever "fixing" their incorrect notion of data, with yet another incorrect understanding of the data, ad infinitum. They love this glorious exercise, and they call it REFACTORING. Sometimes every three months, sometimes every month.

Anyone who refactors their database, by that act, proves himself to be a complete idiot. Why ? because
1. the structure of the universe (which the database is a subset of) does not change (yes, the content does, but not the structure)
2. thus the structure of the database which is a subset of the universe, the structure of which never changes, should not change
Therefore if it changes, it is not a database, let alone a Relational database.

But that aspect, too, is corrupted by the "theoreticians" and their mountain of pig poop. I do not have a problem with people who eat pig poop, I have a problem when they feed it to normal humans, when they market it as "science".

Part of the problem here is, the myopic OO/ORM mindset, that data is merely a slave to a single app. They lie when they say, you can access the data via an API, which they will give you. It is a lie because the do not mention that (a) the data will be refactored monthly, and (b) the API have to be re-written monthly, and (c) thus will be full of errors.

The other part of the problem is the evil geniuses who propagandise that this method is valid or justified, who supply "academic papers" which serve as "theory", to justify such insanity. They even provide anti-solutions to the various and unavoidable problems, which the sane call band-aids, adding layer upon layer of complexity, while failing to recognise the problem for what it is. Again, the total ignorance of Codd's /Relational Model/ by said "theoreticians" ensures that data problems are not identified as such, and the anti-solution provided addresses the incorrect space (adding yet more complexity to the third tier or the monolithic client app, or both).

Further, that is in horrendous denial of the fact that databases are supposed to be open, and any report tool (from Excel to Claris to BusinessObjects) can be used to access the data and report from it. In ways that were not imagined at the app implementation stage. So they call this anti-architecture, or non-architecture, a "closed" architecture as a complement to Open Architecture

AFAIC, building an app with such non-architecture, given that the Open Architecture Standard has been available since 1984, is a criminal act. Even the sales people from the SQL platform suppliers (not the non-platforms; not the non-SQLs fraudulently declaring "sql" in the name) can describe it correctly, and do so before the sale, in order to demonstrate that you (the builder) can produce a completely secure and open database.

Users should be able to write reports to access their data (they own it). They should not be forced to go to the developer to get him to write a report that is stuck in the "closed" paradigm. And that will keep changing, giving the idiot a job for life.

> The other part of the problem is the evil geniuses who propagandise that this method is valid or justified, who supply "academic papers" which serve as "theory", to justify such insanity.

There are hundreds of such "academic papers", one may say, some good, some bad, but I say, all invalid, because they [fail to understand the problem] and thus fix the problem in the incorrect subject space. And such fixes are never-ending, and innumerable. The pip-poop eaters have parties, and laugh at the chaos they have created. They are not interested in the real world, or real world problems that are consequent to the implementation of their sick "theories", they are only interested in defending their sick "theories" with more sick "theories".

It is like selling you gonorrhoea labelled as "relational database design", and when you have problems with the gonorrhoea, that they did not tell you about, they sell you syphilis as the "fix" to /your/ gonorrhoea.

----

1. Please read this article. It is a response to one such "academic paper" which purports to "fix" a well-known problem that exists in the typical OO/ORM implementation. It provides the correct identification of the problem, and the solution (genuine Relational modelling) which in fact eliminates the very existence of the problem. After that, please ask specific questions.

https://www.softwaregems.com.au/Documents/Article/Application%20Architecture/UTOOS%20Response.pdf

2. Here is response to another such idiotic "academic paper". This item was discussed in this forum, but the "theoreticians" never took it to completion, they never conceded the point. Hence this response is very short, nailing the salient issues, it is not a formal response. It must be noted the the author of the subject article has bothered to devise with yet another abnormal 'normal form" precisely because the real Relational Model is unknown to him, and the reason for that is, the "theoreticians" in this space have flooded it with pig-poop branded as "relational". So he dutifully determines a problem (of the millions, in that false "relational" space) and provides a solution, blissfully ignorant that the problem simply does not exist in the Relational paradigm.

https://www.softwaregems.com.au/Documents/Article/Normalisation/DNF%20Data%20Model%20B.pdf
https://www.softwaregems.com.au/Documents/Article/Normalisation/DNF%20Data%20Model%20D.pdf

(There are four docs in the same directory [A][B][C][D], if you are interested in the progression.)

I should write that up as a single formal response.

----

This post can be summarised as defining one aspect of Open Architecture, namely a correct data vs process approach, two separate subject areas, instead of the hilariously stupid OO/ORM single subject area approach, and its myopia. It eliminates the ORM altogether, and the consequent "refactoring".

>> This is a substantial subject, so I have opened a new thread.

> Here is another increment.

More, next time. Yes, there is much more.

Cheers
Derek

[Derek Ignatius Asirvadem]

> On Monday, 6 July 2020 20:37:03 UTC+10, Derek Ignatius Asirvadem wrote:
>

> This is a substantial subject, so I have opened a new thread.

That post provided an Introduction and overview.

> On Wednesday, 15 July 2020 21:40:11 UTC+10, Derek Ignatius Asirvadem wrote:
>
> Here is another increment.

> This [that] post can be summarised as defining one aspect of Open Architecture, namely a correct data vs process approach, two separate subject areas, instead of the hilariously stupid OO/ORM single subject area approach, and its myopia. It eliminates the ORM altogether, and the consequent "refactoring".

Here is the next increment.

As detailed in my previous post, the concept is to move away from the anti-architecture of the Hammer "developer" who sees all problems as Nails, and thus sees their decrepit Record Filing System as a slave of the app, the only purpose of which is to "make persistent" the non-persistent Objects in their app. Notice that the app keeps changing,
- due to the analysis and design of the requirement being absent,
--- in turn due to lack of decomposition/composition being absent in the anti-standard UML, and
--- total lack of genuine education,
and the wireframes and pretty pictures of /skins/ have been elevated to celebrity level, in order to make the sale and obtain funds for the never-ending next version of the app.

And because the idiotic Objects keep changing, their persistence-demanding RFS records keep changing. Enter the insane world of Refactoring. Like a menstrual cycle, unquestioned and without understanding.

Therefore for such "developers", the alternative needs to be enumerated and understood, so that the "developer' has at least a Hammer and a Screwdriver in his sparse toolkit, so that he *can* move away from the hilarious monolith that he calls "architecture" Compare this:
____http://geek-and-poke.com/geekandpoke/2013/7/13/foodprints
versus
____http://www.softwaregems.com.au/Documents/Article/Application%20Architecture/Open%20Architecture.pdf

It is not actually an alternative in the sense that it was established in the 1960's, in both pre-DBMS platforms such as C/ISAM-like Filing Systems, as well as the pre-Relational DBMS platforms, and thence in Relational DBMS. That is why the date I gave was 1984 (first genuine Relational DBMS outside IBM), and perfection in 1990 (as I personally experienced it in Sybase). The point is, it was the established standard, the established method, from the 1960's onwards, and the new kid on the block was the myopic OO mindset, soon to be followed by the brain-dead OO/ORM mindset (my Hammer is 24 carat gold and I can break rocks with it ... I just need to keep replacing the Hammer ... and the rocks).

You can't make this stuff up.

And we need to appreciate that these "developers" were not merely forging their narrow path to hell on their own, they were (and still are) enabled by the "academics" and "theoreticians" who write papers that (a) deny the real world (what a database is, what DBMS platforms provide since the 1960's), (b) thus in total ignorance of those requirements, and (b) justify myopia and a single-tool mindset. It is nothing short of schizophrenia: persistent denial of Reality, and obsession with fragments of the universe, divorced and isolated from the context in which they actually exist. As evidenced in the Responses that I provided as links.

Put another way, if there had been genuine academics and theoreticians in this space in the 1970's, they would have written papers that defined or at least enumerated the method of implementing the established standard in the DBMS space, and if they existed in the 1980's, they would have written papers that defined or at least enumerated the method of implementing the established standard in the RDBMS space. As evidenced in the record of the history of this space, genuine academics and theoreticians did not, and still do not, exist.

Thus only high-end data modellers and app designers, who used high-end RDBMS platforms, both of whom esteem Standards, carried on the Open Architecture Standard. We ignore the filth that is spewed and marketed by the pig-poop eaters, we are quite aware of the several quite different Standards that are necessary to build a stable app and database, and we have several tools in out toolkits, each to suit a purpose.

Thus answering your question requires the enumeration of the ancient Standard, and we have to note it is a paradigm shift away from the myopic, anti-theory world of OO/ORM, into the real world of databases and Open Architecture. And after 1984, the real world of Relational databases.

Hence the title of this thread:
____[ [Relational] Database] Open Architecture Standard
The Standard existed as THE Method prior to DBMS, it was rendered for DBMS when those platforms became available, and rendered again in SQL when RDBMS platforms became available.

Note here that the program suites (they are not servers, they are not platforms) that fraudulently propose SQL compliance do not have the necessary facilities, and thus cannot be used with confidence. (One has to rewrite the entire system when the pain becomes painful enough to warrant adherence to Standard SQL.) These freaky suites (it is 2020, yes, and they still remain clueless about Server Architecture) include Oracle and every "open source" "sql" suite.

That is to say, one cannot obtain ACID from a suite of "DBMS" programs that do not provide ACID, one cannot obtain OTLP from a suite of un-architected "DBMS" programs that do not provide OLTP. No matter what the shiny marketing brochures state.

----------------------
-- Paradigm Shift -- Persistence
----------------------

OO/ORM is broken. It never was a valid method:
a. because it is based on false principles, and
--- I have a Hammer and all problems to be solved are Nails (Objects)
--- I just have to make the Hobjecks persistent
b. because it denies the requirements of a [Relational] Database
--- The database provides persistence, darling child, not the Hobjecks, precisely because it is Data and not Object
--- In the form of ACID: the [C] means Consistent within the definition of the database; the [D] means Durable, lasting after the software Object has ceased to exist.

I won't enumerate [a], the mountain of evidence, 25 years of broken apps with RFS slaves, 95% of the systems out there, should suffice. I will enumerate the Open Architecture Standard, as requested. Which is again, the responsibility of the academics and theoreticians in the space, and which is as evidenced woefully a void, and thsu theoretically based practitioners such as I have to fill in.

Trying to make the Object, which by definition is a software Object that exists fleetingly, for the duration of its use, into a hard Object, that is persistent (Durable), a requirement that the database already has, and is, is hysterically stupid.

Over 25 years of OO/ORM insanity, and it has never worked anywhere. So get with the program, and find out how to do the whole she-bang properly. Forget about the hysterical Hobjeck persistence and get the persistence you need in the database that already provides persistence.

In essence, OO/ORM is app-centric and database-denying, the shift is a return to the established standard which is database-centric, with no denial (denial is a mental illness).

----------------------
-- Paradigm Shift -- Versioning
----------------------

The concept of each user obtaining a Version of the part of the database he is inspecting, is false. Multi Version Concurrency Control is based on that false principle. One academic Nicola seemed to be interested in that subject, and I dutifully opened a thread, but he has not progressed it. Please read, I will not repeat that info here.
____MVCC, Advantages & Disadvantages
____https://groups.google.com/d/msg/comp.databases.theory/f474bCuvZ_A/hwyReZhtBgAJ

The reason it is false is, it contradicts the fundamental principle of a database. If you have to ask, /how so ?/, you are by definition, ignorant of what a database is. I have tried to get the freaks who allege they are academics and theoreticians to define what a database is, in another thread, but it did not progress. Why ? again, it mere proved that they do not have a clue.

Not defining what a database is in entirety, but focussing on the one property that is relevant to this thread.
____A database is a central repository of data assets that belong to a corporation.
In order for such a thing to be central at all, it must contain a single version of the truth.
- Not one fact in several places but one fact in one place (Normalisation).
- Not one fact in several versions but one single version of a fact.

Truth is single, falsity is multiple.

That is Objective Reality, that can be relied upon.

But the "academics" and "theoreticians" who provide no service at all since 1970, but instead flood this space with their pig poop, are not attached to Objective Reality. Oh no. Since the freak Einstein, since the introduction of relativism (note the ism) as "science", the degradation of science into pig poop, they have enjoyed the fantasy of Subjective "reality". Again, I do not have a problem with the insane eating pig poop or dog poop or whatever they fancy, I have a problem when they attempt to feed us pig poop, when they force-feed pig poop to young minds as "education", and thus cripple them.

OLTP/ACID Transaction • Sanity
The sane person operating in an OLTP context (many active users; high throughput; ongoing changes), knows, when he fetches a row from the database, the row content is obsolete from the moment of the fetch. And thus his OLTP system (database with ACID Transactions, which is the database API), is programmed to operate in that OLTP context, and operates perfectly. The database continues to hold the one and only version of a fact, and the methods are faithful to that fact and the OLTP context.

- No locking during Transaction Preparation
- Small tight locking during Transaction Execution
- Rows going obsolete during Transaction Preparation is skilfully handled in the OLTP Standard (Transaction Template)
- No clever thinking required (no Deferred Constraints)
- The event of rows going obsolete is reduced by the normal behaviour in the OLTP context, such as, do not fetch a row and then take a break
- No deadlocks
- Blocking locks block for the shortest duration, permitting that which was blocked to continue

Versioning • Insanity
But the insane person says, when I fetch a record from the Record Filing poopstem, it is mine and mine alone, for eternity. Everything I see on that screen is trah-whoo and will be trah-whoo for eternity. because I am God, and there is no other God. Because I am alone in the universe and there are no other users in the RFS. It is mine alone to do with as I will.

I will grab a coffee, visit the washroom to wipe the drooling pig-poop off my chin, and return to complete the non-transaction when the drool is dry and I have had a fresh suck at the porcine rectum.

Um, the Objective Reality is, the record is long gone, the record on his filthy screen is obsolete. But the freak is going to proceed with the non-transaction, as if the record on his screen is trah-whoo, because his pathetic subjective "reality" is trah-whoo, and no one else exists on the planet or the system. The cult of mE; mySelf; and I, the unholy trinity.

The crime is two-fold, as always. First, the creep has to deny that the purpose of the central RFS is to maintain a single version of a fact (schizophrenia). Second, he has to elevate his out-dated version of the record to the level of that single version, in order to proceed with his non-transaction (schizophrenia). An act of fantasy (schizophrenia). Again, in denial of the reality, that the RFS is online, and that many users are updating records (schizophrenia). Four separate counts of certified insanity.

How to do that, how to erect fantasies ? Why, the glorious idiot Stonebraker [Porcellus Maximux] gave us the voluminous excreta called Multi-Version Concurrency Control. Known to sane people as pig-poop that (a) will cause a massive resource load, that (b) in and of itself contradicts an OLTP model of any kind, and (c) cannot work because it breaks the fundamental principle of what a database is.

But THIRTY YEARS of pig-poop that has not worked does not faze our self-obsessed hackademicks and fearetishuns. Oh no. They perform masses of wee-such, and erect mountains of software containing multiple version of the single version of the fact. And when the records are contentious, multiple versions squared. Squared, not doubled.

Even the name is a disgusting lie, a self-contradiction. Multiple versions is the antithesis of concurrency control. One has:
- EITHER concurrency control, which prevents multiple versions
- XOR multiple versions, which have no concurrency control, but may have version control.

And now that the pig-poop that has not worked for THIRTY YEARS is causing a bit of a stink in any system with more than five active users (just peruse StackOverflow for your favourite MVCC problem that ACID does not have), they are now going to perform MORE masses of wee-such, and erect yet another mountain of pig-poop on top of their thirty-year-old mountain of pig poop. They call it "Two-Phased Locking".

The sane call it insanity.

Here is another nugget that the insane cannot notice (as distinct from wilful denial) due to their retardation, and lack of intellectual integrity, the "normal" condition of the insane. If you inspect "Two-Phase Locking", you may notice that the two phases are required for SERIALISATION of the various and numerically advantaged multiple versions of one single fact, each taken at different points in time, and the need for serialisation is (wait for it) based on the principle of (I said wait) a single version of the fact. Ring any bells ? Hello ?

So let's get this straight. First, the pig-poop eating neanderthals deny the principle of the single version of a fact. Second, they allow each user to obtain /and hold/ their numerous private versions of the fact. Third, they allow the database to keep changing, unhindered by the fact that that row or page is currently in a state of change. The Joy of Liberty. Yes, folks, liberty from sanity. Fourth, if and when one user decides to COMMIT his now-ancient version to the database, oopsey doopsey, the great of brow and small of cranium labour through the mountain of versions, and the dependencies between versions, and the yes-buts, and the what-ifs, in their urgent attempt (at best it is an attempt, because it does not work) to serialise what they have denied serialisation to in the beginning. And fifth, they need "Two-Phased Locking" to attempt that serialisation.

Because the sane are not crippled by the insanity that is the consequence of eating pig-poop, here particularly the pathological denial of reality, they just serialise that which demands serialisation, right at the point that it needs to be serialised. And the second; third; fourth; fifth MVCC steps are eliminated. That is responsibility. No pretence at providing private subjective versions of "reality", because that is the first sin, the first increment, into madness. No, a single version of the fact is maintained, and multiple versions are given to the sows and their sucklings. Commit, by any user, has very little work to perform: only that of the changes that user made, no mountain of diarrhoea to wade through on each and every Commit.

But the Stonebraker sucklings will have none of that. After all, who am I, from the real world where Ordinary Locking and OLTP has worked perfectly for seventy years (forty years for RDBMS), to be enumerating that which works, when they have That Which Breaks But Will Work 40 Years From Now, Promise. Obsession with filth, Stonebraker; Ingres; MVCC; That Which Breaks, is much more enjoyable than resolving anything for the masses that are expecting something (please God, anything) from the hacks and fears.

After all, I am just a practitioner, along with the genuine high-end RDBMS suppliers, who produce applications. And they are the "academics" and "theoreticians" that produce nothing. For fifty years.

But you did ask.

----

Back to Persistence of Objects.

It is this insanity; this denial of Reality; this mountain of "academic" and "theoretical" pig-poop; this anti-reality; this freaky petulant demand for completely false subjective "realities" aka versions", that the notion of Object Persistence is erected upon. It is stupid in the database, and it is stupid in the Object.

That is separate to the idiocy of trying to anoint Objects with the property of Persistence when the Persistence is beyond the scope of an Object, and it is already persistent in the database.

----

To sum up.
- You have to give up the false and broken notions of Object Persistence and Versioning, and take up the principles of a database, that has a single version of a fact.
- Objects are software articles that exist for the duration of its execution.
- Rows in a database are hard, already persistent.
- You have to shift from a paradigm that is self-obsessed, version-centric, and object-centric, to the natural and real universe, which single version of the truth, and database-centric.
- That is, to shift out of the fantasy world, and into the real world.
- Where versions and the massive MVCC resources required to support them (and the 2PL required to feebly fix the MVCC), are not required.

Cheers
Derek

[Derek Ignatius Asirvadem]

The following thread is relevant to this one.
__ https://groups.google.com/g/comp.databases.theory/c/LSoYp9wrv0M

Cheers
Derek

[Derek Ignatius Asirvadem]

Nicola

It may be worth taking an *Inventory* of the chasm between the fictitious world that the academics who allege to serve this field have established in their collective mind, and the real world that has progressed since Dr E F Codd's /Relational Model/ in 1970. The high end of the industry gives a sharp contrast. Of course, nothing the marvellous academics have produced in their hundreds of papers can be, or have been used, by us (the low end and middle do love the ever-changing "truths', they are quite used to "refactoring" their filing systems, and to never-ending "inheritance" problems).

In this thread I attempted to assert the implementation of Relational databases that comply with the Open Architecture Standard that we have had since the Client/Server model was established in the 1980's (Britton-Lee proprietary in the 1970's; Sybase as non-proprietary and a model). Refer Transact-SQL and all the products that served it, until today. It has not progressed due to the [predictable] non-participation by academics.

In the *No CASCADE in Commercial SQL & Benchmark Considerations* thread, we somewhat ventilated just one subject: ACID Transactions, which is essential to any database system, not only one that complies with Open Architecture, or one that requires high concurrency (and there are degrees to it, as you saw). Otherwise "transactions" are naïve, unconscious, and uncontrolled creatures that are spread across the network. I commend you for your participation therein.

In the full context of an implementation of a Relational database then, as opposed to discussing fiction, when you are ready, you may be interested in the other subjects that the academics have steadfastly maintained their ignorance of, for FIFTY YEARS. In the implementation sense (ie. product availability) for forty years. Here is a picture I drew up many years ago, that names the other subjects:

____ https://www.softwaregems.com.au/Documents/Article/Database/Relational%20Model/Relational%20Landscape.pdf

Cheers
Derek