mySQL Keys

[snoopy]

Hi,

ich verwalte registrierte Benutzer in einer mySQL-Datenbank-Tabelle. Dabei habe ich bisher den Usernamen als Primary-Key definiert, da jeder Benutzername natürlich nur einmal vorkommen soll.

Nun kann ein Benutzer aber verschiedene Aktionen ausführen, wobei dessen Ergebnisse wiederum in einer Datenbank gespeichert werden sollen. Natürlich soll man diese Ergebnisse den einzelnen Usern zuweisen können, was ja theoretisch über den Primary Key (der Username) möglich ist.

Doch frage ich mich, ob eine ID als PrimaryKey nicht besser geeignet ist. Auf diese Weise kann man sicher eine Menge Bytes in der Datenbank sparen. Den Usernamen kann ich doch dann als Unique Key machen richtig?
Oder wäre es sogar besser beide (Username, ID) getrennt als Primary zu nehmen? Meine Fragen sind also eher auf die Technik bezogen :)

Gruss
snoopy

[Rafael]

Du meinst die Bytes in bezug auf den Index, oder?
Da kannst du wenig sparen. Die Nutzernamen sowieso nicht und wenn du ohnehin einen Unique-Index definieren willst, dann sparst du auch hier nichts. Insofern: Nimm ruhig den Nutzernamen.

[dedlfix]

echo $begrüßung;

Doch frage ich mich, ob eine ID als PrimaryKey nicht besser geeignet ist [als ein Username]. Auf diese Weise kann man sicher eine Menge Bytes in der Datenbank sparen. Den Usernamen kann ich doch dann als Unique Key machen richtig?

Mach dir um die paar Bytes keine Gedanken. Speicherplatz sollte mit den heutigen technischen Gegebenheiten kein Problem darstellen. Interessanter ist die Frage, was passieren soll/muss, wenn ein Benutzer seinen Namen ändern möchte. Dann musst du ihn an allen Stellen, an denen du diesen Namen als Fremdschlüssel verwendet hast, ebenfalls ändern. Insofern ist ein bedeutungsfreier Schlüssel einfacher, der kann einfach so bleiben.

echo "$verabschiedung $name";

[snoopy]

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

Gruss
snoopy

[Vinzenz Mai]

Hallo

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.

Ein kombinierter Primärschlüssel über die Spalten ID und Benutzername ist nicht
sinnvoll, denn in diesem Fall dürfen sowohl die ID als auch der Benutzername
mehrfach vorkommen.

Freundliche Grüße

Vinzenz

[Tom]

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