> 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:
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
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.