Follow @DBDebunk Follow @ThePostWest

Note: I am working on entirely new papers (not re-writes) in the PRACTICAL DATABASE FOUNDATIONS series. I have already published two:

THE FIRST NORMAL FORM - A DEFINITIVE GUIDE

PRIMARY KEYS - A NEW UNDERSTANDING

available for ordering from the PAPERS page, and two more:

RELATIONAL DATABASE DOMAINS: A DEFINITIVE GUIDE

DATABASE RELATIONS: A DEFINITIVE GUIDE

are in progress.

In the process I am coming across industry common and entrenched "pearls" that I am using for my "What's Right/Wrong with this Database Picture, or "Setting Matters Straight" (SMS), and "To Laugh or Cry" (TLC) posts on Linkedin. I do these posts to enable the few thinking database professionals left realize how scarce foundation knowledge is, and to illustrate fallacies that abound in the industry, of which they are unaware, and which the papers are intended to dispel.

Time permitting, I may specify those fallacies in brief posts that I set straight in the papers, such that those thinking professionals can test their knowledge and decide whether the papers are a worthy educational investment.

Here comes the first, a TLC I just posted on LinkedIn:

 

 “The company was using a [SQL] RDBMS . . . to handle data transactions for its trading applications. However, the applications required arbitrary data types, which is nearly impossible for relational systems, according to experts.”

which contains three fallacies--can you identify them before you proceed?

------------------------------------------------------------------------------------------------------------------

SUPPORT THIS SITE
DBDebunk was maintained and kept free with the proceeds from my @AllAnalitics column. The site was discontinued in 2018. The content here is not available anywhere else, so if you deem it useful, particularly if you are a regular reader, please help upkeep it by purchasing publications, or donating. On-site seminars and consulting are available.Thank you.

LATEST POSTS

02/05 METALOGICAL PROPERTIES Part 2: Assertion Predicate

02/09 METALOGICAL PROPERTIES PART 1: Designation Property

UPDATES

02/17 Renovated the LINKS page and renamed it REFERENCES

LATEST PUBLICATIONS (order from PUBS pages)

02/2024 PRIMARY KEYS: A NEW UNDERSTANDING

01/2024 FIRST NORMAL FORM: A DEFINITIVE GUIDE

10/16 THE DBDEBUNK GUIDE TO MISCONCEPTIONS ABOUT DATA FUNDAMENTALS, my latest book (reviewed by Craig Mullins, Todd Everett, Toon Koppelaars, Davide Mauri).

USING THIS SITE
- To work around Blogger limitations, the labels are mostly abbreviations or acronyms of the terms listed on the SEARCH  page. For detailed instructions on how to understand and use the labels in conjunction with that page, see the ABOUT page. The 2017 and 2016 posts, incl uding earlier posts rewritten in 2017 were relabeled accordingly. As other older posts are rewritten, they will also be relabeled. For all other older posts use Blogger search.
- The links to my AllAnalytics columns no longer work. I re-published only the 2017 columns @dbdebunk, and within them links to sources external to AllAnalytics may or may not work.

SOCIAL MEDIA
I deleted my Facebook account. You can follow me @DBDdebunk on Twitter

------------------------------------------------------------------------------------------------------------------

"SQL RDBMS" is a contradiction in terms. Not only are SQL DBMSs not relational (and, thus, fail to provide RDM's advantages), but--even leaving SQL out--the interpretation (and, thus, understanding, such as it is) of RDM dominant in the industry is flawed. Do you know why, and what are the missed advantages?

"Arbitrary data types"--more precisely, domains of arbitrary complexity (not to be confused with SQL built-in types)--are not impossible in RDM properly understood, namely, as coupled with a strong type system: a notion of type hierarchy derived from a theory of types that governs manipulation of domain values, which is orthogonal to RDM, albeit necessary, for support of domains in general, and those so-called "complex" in particular (orthogonal in the sense that the relational data sublanguage is insulated from the implementation of the domains and their operators). Such a type system is incorporated in McGoveran's Semantic-Relational Data Model (SRDM)--the correct interpretation, extension and formalization of Codd's work.

As to "experts", I do not know many (to understate the case) in RDM and I assure you that the above statement was not made by any of them.

References

McGoveran, D., LOGIC FOR SERIOUS DATABASE FOLK (draft chapters), forthcoming.
Pascal, F., RELATIONAL DATABASE DOMAINS, forthcoming.