Tom: Trennung von Daten und Schlüsseln

Beitrag lesen

Hello,

Also nehme ich eine ID als Primary Key. Und was mache ich mit dem Benutzername, der nur einmal vorkommen darf? Ebenfalls Primary oder Unique?

Unique.
Du kannst nur einen Primärschlüssel haben.

Diese Aussagen bedürfen der näheren Betrachtung, weil sie sie mMn zu oberflächlich und zu allgemnein sind.

Hier unterscheiden sich Theorie und Praxis und es wundert mich, dass gerade Vinzenz das so mit zwei hingeworfenen Sätzen abtut.

Es geht hier um das dynamische Design einer Datenbank. Als sie angelegt wurde, war es richtig, den Usernamen, der ja Datenwert ist, als Schlüssel zu verwenden. Eer wurde sogar zum Primary Key gemacht. Nach den gegeltenden Regeln war das sogar richtig.

Nun sollen aber weitere Tabellen einbezogen werden in das Design und es zeichnet sich ab, dass es nicht mehr länger sinnvoll ist, den Usernamen, der ja immer noch Datenwert ist, als Primary Key und nun demnächst auch Foreign Key weiter in die Datenbank zu tragen.

Meine Meinung ist: Datenwerte dürfen keine Primären Schlüssel sein. Es besteht immer die Gefahr des Änderungswunsches. Als primäre Schlüssel sollten grundsätzlich verlorene Schlüssel benutzt werden. Das bietet zudem auch die Möglichkeit, sie ordinal anzulegen und dadurch auch gleichzeitig die Reihenfolge der Vergabe zu signieren. Derartige künstliche Schlüssel haben dann als "Echte Schlüssel" eine unbegrenzte Lebensdauer (frühzeitige Migration des DBMS von Longint auf Bigint auf Verybigint auf Ultrabigint auf ... vorausgesetzt). Damit ist eine Grundforderung erfüllt: Trennung von Daten und Verwaltungsinformation (Schlüsseln) des DBMS.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)