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 and forthcoming, respectively.
In the process I am coming across common and entrenched industry "pearls" that I am using for my "Setting Matters Straight" (SMS) and "To Laugh or Cry" (TLC) posts on Linkedin. I do those 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 expose and dispel some of those fallacies, treated in more depth in the papers, such that those thinking professionals can test their knowledge and decide whether the papers are a worthy educational investment.
Here's one.
“A domain in most SQL usage is essentially an alias name for an existing type + restrictions on an existing type that can be used in a column. As for an attribute, it's essentially a COLUMN in SQL, a field in other types of databases, etc.”
Can you identify the fallacies before you proceed?