Follow @DBDebunk Follow @ThePostWest

The Web is chockful of unnoticed/unquestioned pronouncements by self-taught novices or "experts" that are (1) wrong, or (2) gobbledygook. Any attempt to demonstrate lack of foundation knowledge underlying these misconceptions and their practical implications are usually dismissed as "theory that is not practical", attacked as "insulting ad-hominem", or ignored altogether, regardless of the amount and quality of the supporting evidence and argument logic. This is understandable: in the absence of foundation knowledge and ability to reason, it is by definition impossible to comprehend and appreciate corrections that require them.

I have always contended that practitioners who cannot detect such misconceptions, and understand their practical implications and the importance thereof are insufficiently prepared for a professional career in data management. Worse, neither can they associate problems with their real causes and, thus, cannot come up with proper solutions, which explains the industry's "cookbook approach" and succession of fads.

What about you? This is another batch in the Test Your Foundation Knowledge regular series of posts of online statements reflecting common misconceptions that are difficult to discern without foundation knowledge. You can test yours by trying to debunk them in Comments -- what category, (1) or (2) do they fall in? 

“...foreign keys that are mutable are a really bad idea, but with the maths and technology available when Codd invented relational databases we were more concerned with transactional systems than today's interactive systems. One of the reasons I invented Unibase was to migrate calculations from the domain of the program to the domain of attributes. In my world calculations are attributes, but that needs a very special AI engine to manage. The correct way to view all attributes is as members of a mathematical group. (More than a set). Define the operators that are valid. eg invoice numbers are not numbers. You can't add two of them together. They aren't text either. Like photons, they exhibit characteristics of both worlds but are not defined by them.”

“...a data model is a deep schema: an expression in various forms of the constraints that act upon both scalar data primitives and structural relationships that make up a given dataset. It may or may not be closed. It should generally express cardinality relationships. It may be annotational but this is not strictly necessary.”

“What Codd did was important, but over the last fifty years, the term data model has picked up a lot of baggage. It's one reason I prefer ontology over either data model or schema. Codd's definition is also too technical for people outside this space.”

“Data models are data structures, all which inherit baseline characteristics from linked lists, which are the barista for all data structures. Linked lists and folds are not cookbook, that’s CS 101. Has nothing to do with frameworks. In which folds are performed on, regardless of language or framework that takes you so far away from what it really is you don’t understand it. Are you saying the fundamentals of all data structures are not linked lists?  You sir, are officially on the do not hire list.”

Source: Data Mutability: The Shark that lurks in Data Modeling Waters