Einfache Datenbanktabellen: Würdet ihr über ID oder Bezeichnung in die Tabelle gehen?
Beispiel: Es gibt eine Tabelle Abteilungen, die im Wesentlichen nur aus ID + Abteilungsname besteht
ID Name
123 Produktion
124 Versand
128 IT
...
Wenn ihr die Mitarbeitertabelle befüllen wollte, in der es einen Fremdschlüssel ABTEILUNG_ID gibt, würdet ihr im Quelltext die IDs direkt als Konstanten anlegen und verwenden, also
insert into MA (... ABTEILUNG_ID...) values (...' + constProduktion_ID + '...)
oder würdet ihr die ID anhand des Namens lesen
insert into MA (...ABTEILUNG_ID...) values (...(select abt.ID from ABTEILUNG abt where abt.Name = ''Produktion'')...)
Die erste Variante hat den Nachteil, dass man die ID nicht ändern darf. Löschte man beispielsweise den Eintrag für Produktion und fügte ihn erneut ein, würde die Abteilung nicht mehr unter der alten ID gefunden werden. Man müsste die Konstante für die ID im Quelltext anpassen.
Die zweite Variante hat den Nachteil, dass der Name sich nicht ändern darf, weil der Subselect sonst ins Leere laufen würde.
Irgendwie erscheinen mir beide Varianten suboptimal, aber die erste sogar besser, weil die ID sich nicht so häufig ändern dürfte. Programmiertechnisch fühlt es sich dennoch falsch an, die IDs als Konstanten zu speichern und direkt ins Fremdschlüsselfeld einzutragen.
Bei den Abteilungen mag das vielleicht unkritisch sein, weil man normalerweise eine Oberfläche mit einer Auswahlliste an Abteilungen anbietet, die in der Datenbank zur Verfügung stehen.
Was ist aber mit anderen Feldern, die unterschiedliche Stati oder Bereiche darstellen oder wenn Einträge erfasst werden, die Standardwerte verwenden und nicht auf einer Eingabe aus einer Benutzeroberfläche her rühren?
Beispielsweise soll in einer Applikation für die Produktion automatisch die Abteilung auf 123 (Produktion) gesetzt werden.
Hat jemand von euch einen Rat?
4 Antworten
Konzeptionell sollten IDs immer auch unique sein. In wieweit (zumindest innerhalb einer Verwaltungaeinheit) der Abteilungsname eindeutig ist, lasse ich offen.
In letzter Konsequenz wäre es sinnvoll etwas zu nehmen, zu dem auch ein Index existiert (was bei Primärschlüsseln eigentlich immer zutrifft).
"ID" ist relativ.
Es ist wichtig, dass es in Datenbank-Tabellen einen eindeutigen Schlüsselwert gibt.
Ob der eine automatisch vergebene ID ist oder ein anderer Wert wie "Name" ist dabei unerheblich. Wichtig ist, dass dieser Wert EINDEUTIG und UNVERWECHSELBAR ist.
(Wobei ich die Bezeichnung "Name" in Deiner Beispieltabelle schon für suboptimal halte!)
Ich nutze immer dann eine automatische ID, wenn es bei den anderen Werten zu Dopplungen kommen kann - z. B. bei (Kunden)Namen.
Und auch dann, wenn sich die Bezeichnungen ändern können - wie z. B. Namen oder Abteilungen.
Im Prinzip könnte man immer eine ID verwenden.
Das ist korrekt.
Es ist nur nicht immer praktikabel.
Beispielsweise bei einer Zuordnungstabelle von Bankleitzahlen zu Banken würde ich keine ID verwenden sondern die BLZ selbst als Schlüsselwert nutzen.
Ja, oft gibt es mehrere, eindeutige Felder oder Feldgruppen, aber selbst in der Bankleitzahlentabelle würde man eine ID-Spalte anlegen.
Ich meine klar, wenn man sich diesem Usus bewusst widersetzen will, kann man die ID-Spalte weglassen, aber meistens werden die Datenbanken so modelliert, dass es trotzdem eine ID-Spalte gibt.
Selektieren kann man selbstverständlich auch über andere, eindeutige Schlüssel.
Das mache ich in der Regel auch so - dann läuft die ID halt "nebenher", wenn ich sie zur Zuordnung nicht dringend brauche. 😉
Speziell bei den Bankleitzahlen hat man ja das Problem, dass heutzutage die Bankleitzahlen gar nicht immer bekannt sind. Sie wurden abgelöst durch die IBAN.
Hat man damals die Bankentabelle ohne ID angelegt mit Primärschlüssel auf die Spalte Bankleitzahl, hätte man heute ein Problem. Die ganzen Select-Anweisungen, die die Bank anhand der BLZ nachlesen, müssten überarbeitet werden und das Eindeutigkeitsmerkmal in der Tabelle müsste auf die IBAN gemünzt werden und zu jeder BLZ müsste die IBAN bestimmt werden.
Eigentlich ein gutes Beispiel dafür, dass man immer eine ID haben sollte, aus Konsequenz und weil man damit auf der sicheren Seite ist.
Soweit ich weiß sind (richtige) IDs sowieso nicht zum Ändern gedacht.
Wenn man bedenkt, dass SQL Datenbanken häufig bei einem UPDATE sowieso den ganzen Eintrag entfernen und neu einpflegen, macht es nur Sinn eine ID nicht zu ändern.
Verstehe. Es wird heutzutage noch nicht einmal häufig gelöscht, weil dann die Rückverfolgbarkeit nicht mehr gewährleistet wird. Da wird mehr mit Flags gearbeitet.
Ich denke, ich werde dann die IDs als Konstanten fest im Quelltext verankern.
Viele Datenbanken erstellen übrigens zu jedem Eintrag auch eine interne ID. Selbst wenn du dann eine eigene ID in der Datenbank hast, gibt es noch dazu die interne ID, die von der Datenbank selbst verwaltet wird. Aber das nur nebenbei.
Ich würde immer eine interne ID verwenden, die sich nie ändert.
Im Prinzip könnte man immer eine ID verwenden. Faktisch sehe ich selten in der Praxis anders definierte Primärschlüssel. Jede Tabelle hat eine ID und diese ist automatisch der Primärschlüssel.