Follow @DBDebunk
Follow @ThePostWest
I have deleted my Facebook account and am focusing my presence on social media on two Twitter pages, DBDebunk, and The PostWest.
Follow: @DBDEBUNK @THEPOSTWEST
On DBDebunk I will tweet links to new posts on this site, To Laugh or Cry? and What's Wrong with This Picture? that I am bringing back there, and occasional links to and comments on items of interest. I have created a #RelModel hashtag for use with it.
On ThePostWest I will tweet links to evidence for, and my take on (1) Dystopian Western Decadence and Decline, including (2) the equivalence of The Only Acceptable Racism Left and The Weaponized Myth of a "Palestinian Nation". I will create a #ThePostWest later on for use with it.
Please make a note of it, disseminate, and follow.
Friday, June 8, 2018
Saturday, June 2, 2018
Monday, May 28, 2018
Sunday, May 20, 2018
Sunday, May 13, 2018
Sunday, May 6, 2018
Sunday, April 29, 2018
A New Understanding of Keys Part 3: Surrogate Key Illusions
Follow @DBDebunk
Follow @ThePostWest
Note: This the third of three re-writes of older posts to bring them in line with McGoveran's formalization and interpretation[1] of Codd's true RDM. They are short extracts from a completely rewritten paper #4 in the PRACTICAL DATABASE FOUNDATIONS series[2] that provides a new perspective on relational keys, distinct from the conventional wisdom of the last five decades.
(Continued from Part 2)
As we explained in Parts 1 and 2, keys can be properly understood only within the RDM. We revealed a new perspective on keys, discussed relationally valid kinds of keys, and revised definitions of natural (NK) and surrogate keys (SK).
As we have seen, the formal PK mandate is distinct from PK selection, which may be pragmatic. A PK must represent a name -- either pre-assigned, or generated only when there is no simple name CK. Generated keys must ensure entity integrit and are managed by the DBMS transparently to users.
All this is absent from conventional wisdom and database practice, as the above example illustrates: generated SKs are overused for the wrong reasons, the most common being emulation of OIDs (a SK -- often database-wide and, so, unique across relationsn), followed by performance.
Note: While OIDs have unique values, they often also have some physical significance.
Note: This the third of three re-writes of older posts to bring them in line with McGoveran's formalization and interpretation[1] of Codd's true RDM. They are short extracts from a completely rewritten paper #4 in the PRACTICAL DATABASE FOUNDATIONS series[2] that provides a new perspective on relational keys, distinct from the conventional wisdom of the last five decades.
(Continued from Part 2)
"When defining a surrogate primary key for a [SQL Server] table, two options are the most common: Integer and UniqueIdentifier (aka Globally Unique Identifiers, or GUID's) ... Historically, Integer has been the logical choice. It’s human-readable, requires minimal storage, and can be set as an identity (auto-incrementing) to prevent the need for additional application logic. UniqueIdentifier comes with significant disadvantages. The most immediately noticeable is that it’s user-unfriendly. You’ll never hear a user or developer ask you about record “A78383A3-4AB1-42CF-B3FC-A4A23AD10398”. With high availability and replication becoming highly prevalent, UniqueIdentifier is being chosen more often, but has caveats that mean it isn’t always the optimal solution."
--Jeffrey J. Keller, Vertabelo.com
As we explained in Parts 1 and 2, keys can be properly understood only within the RDM. We revealed a new perspective on keys, discussed relationally valid kinds of keys, and revised definitions of natural (NK) and surrogate keys (SK).
As we have seen, the formal PK mandate is distinct from PK selection, which may be pragmatic. A PK must represent a name -- either pre-assigned, or generated only when there is no simple name CK. Generated keys must ensure entity integrit and are managed by the DBMS transparently to users.
All this is absent from conventional wisdom and database practice, as the above example illustrates: generated SKs are overused for the wrong reasons, the most common being emulation of OIDs (a SK -- often database-wide and, so, unique across relationsn), followed by performance.
Note: While OIDs have unique values, they often also have some physical significance.
Subscribe to:
Posts (Atom)