[DB-Design] "IDs" als Integer oder String?

[Shaun]

Hallihallo,

ich habe letztens - übrigens zum ersten Mal - gehört, dass es sich "nicht gehört" in Datenbanken mit IDs zu arbeiten so wie ich das tue, sondern mit "Text-IDs".

Zur Erläuterung:

Im Moment erstelle ich eine Datenbank mit allen Sportvereinen in unserer Stadt. Natürlich will ich da auch wissen, welche Sportarten der jeweilige Verein anbietet und habe daher 3 Tabellen:

Sportvereine

- ID (INT AUTOINCREMENT)

- Name (Varchar)

- ... (Daten des Vereins)

Sportarten

- ID (INT AUTOINCREMENT)

- Bezeichnung

- ... (weitere Infos zur Sportart an sich)

um das jetzt zu verknüpfen habe ich eine weitere Tabelle erstellt:

Sportarten_Vereine

- Sportverein_ID

- Sportart_ID

So habe ich das damals in der Schule gelernt. Jetzt hat aber ein Bekannter sich mit einem "Profi" unterhalten und meinte das wäre totaler Müll, man könnte ja auch, damit die Datenbank "robuster" wird direkt den Namen der Sportart hineinschreiben und könnte sich dadurch nicht so schnell die Datenbank zerschiessen.

Für mich persönlich hört sich das nach Schwachsinn an, aber ich kann mich ja auch irren... Finde jedenfalls keinen Grund, warum ich nicht weiterhin mit IDs in Form von INT arbeiten sollte.

Vielleicht hat ja von euch jemand eine andere Meinung und kann mich "überzeugen" bzw. hat noch Argumente für "Text-IDs".

[.vash]

Ich bin mir nicht sicher ob der "Profi" eine ID als String speichern will so wie Du oder Dein Bekannter es verstanden haben. Pauschal würde ich sagen Du machst nichts falsch.

Entweder ist der Profi kein Profi (denn wozu gibt es Constraints und dergleichen), oder er meint etwas anderes und keine herkömmliche relationale Datenbank. Frage doch nochmal genau nach was der Bekannte denn tatsächlich gemeint hat.

[carstenj]

Hi,

meiner Meinung nach hängt es von der Komplexität des Datenbankdesigns ob, ob auschließlich Zahlen als ID geeignet sind.

Ich selber mag "sprechende" ID (ich denke wir reden hier von Primary Keys?), aus denen man schon erkennen, worum es sich handelt. Z.B:

cj1976do

Wenn du später diese ID als foreign key verwendet möchtest, wirst du, sofern du nur Zahlen nimmst, wahrscheinlich Probleme bezüglich der Übersicht bekommen.

[.vash]

cj1976do

Ob diese ID sprechend ist, außer für den der sie erstellt hat, wage ich zu bezweifeln. Darüberhinaus ist klar, dass Strings idR mehr Speicher benötigen als Integer. Dazu kommt, dass das sowohl Suchen und Sortieren nach IDs langsamer wird je größer die DB wird.

Zu allem Überfluss sieht der Anwender selten die technische ID eines Datensatzes. Ich bezweifle ernsthaft das Strings für Primary Keys für relationale Datenbanken einen praktikablen Nutzen besitzen wenn ich doch als Programmierer ohnehin Zugriff auf alle Tabellen habe und mir deren Inhalt in allen möglichen Sortierungen anzeigen lassen kann.

Eine ID wie carstenj sie beschreibt würde IMHO höchstens vorhandene Informationen redundant beinhalten und den Sinn und Zweck eines Primary Key ad absurdum führen. Bitte um Aufklärung meinerseits falls ich mich so arg täusche.

[Blacks7]

Wenn du auf einer MS SQL arbeitest, dann nimm nen UniqueIdentifier.

Mit newid() bekomms tdu dann bei jedem neuen Eintrag automatisch einen neuen Unique.

Ist auf MSSQL wesentlich performanter als Intiger, zumal wenn du mehrer Tabellen hast, die imens groß werden, dann ein Unique besser verarbeitet werden kann.

[Jaraz]

Wenn du auf einer MS SQL arbeitest, dann nimm nen UniqueIdentifier.

Ist auf MSSQL wesentlich performanter als Intiger, zumal wenn du mehrer Tabellen hast, die imens groß werden, dann ein Unique besser verarbeitet werden kann.

Mit Sicherheit ist ein 16 Byte Schlüssel(Unique Identifier) nicht so performant wie ein 4 Byte (Integer) Schlüssel. Da müsste MS zaubern können.

Gruß Jaraz

[Blacks7]

UNIQUE ist für Tabellen mit großen Datenmengen der bevorzugte PK.

1. Weil Int bei irgendwann schlap macht und die Zahlmenge überschritten ist

2. Weil Unique als Indice optimiert ist

etc...

Auf Wunsch geb ich mal ne kleine Übersicht

[Shaun]

Also bei mir ist es primär MySQL womit ich arbeite und da wähle ich dann je nach Inhalt der Tabelle die Schlüsselgröße... Ich brauch ja nicht für eine Tabelle wo definitiv < 256 Datensätze hineinkommen 'nen BIGINT .

[geloescht_JesterDay]

UNIQUE ist für Tabellen mit großen Datenmengen der bevorzugte PK.

UNIQUE ist für mich eine Eigenschaft eines Index und der PK ist ja von Natur aus UNIQUE (sprich es darf kein Wert mehrmals vorkommen)

1. Weil Int bei irgendwann schlap macht und die Zahlmenge überschritten ist

Auch deine Text-ID hat eine maximale Zahl an unterschiedlichen Einträgen (*).

Für MySQL sieht es bei Integer z.B. so aus (jeweils maximaler Wert, unsigned):

TINYINT - 255

SMALLINT - 65.535

MEDIUMINT - 16.777.215

INT - 4.294.967.295

BIGINT - 18.446.744.073.709.551.615

Und ich würde gern mal deine Tabelle sehen, bei der ein (BIG)INT-PK überläuft

Und das sortieren nach Zahlen ist auf jeden Fall einfacher und schneller als das sortieren nach einen String. Da kann das auch noch so optimiert sein.

Zum original Beitrag:

Ich als "Profi" halte nichts davon, den Namen als Foreign Key zu verwenden. Zum einen ist eine Zahl schneller, zum anderen nimmt sie viel weniger Platz weg als der String und du hast mit einem String viele redundante Daten (Normalisierung). Klar kann man ja jetzt sagen, eine Zahl steht dann auch mehrfach drin, aber die Zahl ist ja dann nur ein Verweiß auf den Inhalt. Angenommen du hast dich bei einem Namen verschrieben und führst diesen Namen jetzt über mehrere Tabellen und mehrere Sätze als Key mit. Das änderst du nicht mal so. Mit deiner Methode ist das dann kein Problem mal schnell den Namen zu ändern. Die Datenkonsitenz bleibt dabei auf jeden Fall erhalten.

Die Normalisierung ist auf jeden Fall ein Mittel im DB-Design. Wie weit man die treibt hängt immer von einem selbst ab. Ich würde, als Profi, auf jeden Fall dein Design bevorzugen.

EDIT:

*: Wenn es sich um einen 16 Byte Wert handelt, sind das (bei Groß-, Kleinbuchstaben und Zahlen als Werten) genau

62^16 = 47.672.401.706.823.533.450.263.330.816 unterschiedliche Werte. Das ist verdammt viel, aber ein unsigned INT reicht in 99,9% der Fälle wohl aus (und ein BIGINT für den Rest würd ich mal sagen).

[Jaraz]

UNIQUE ist für Tabellen mit großen Datenmengen der bevorzugte PK.

1. Weil Int bei irgendwann schlap macht und die Zahlmenge überschritten ist

2. Weil Unique als Indice optimiert ist

etc...

Auf Wunsch geb ich mal ne kleine Übersicht

Ich habe nicht gesagt, das GUIDs keine Daseinsberechtigung haben, auch wenn ich sie nur in Spezialfällen nutzen würde.

Nur wie gesagt, Performance ist mit Sicherheit kein Pro für GUIDs.

Zur Frage:

Wenn es sichergestellt ist, das sich der String nicht ändert, kann man durchaus char oder varchar als Schlüssel nehmen.

In dem Moment wo aus Federball - Badminton oder Ping Pong - Tischtennis wird, wird das ganze aber problematisch.

Gruß Jaraz

[.vash]

Anders wiederum ist es wenn Du nur einen Verweis machst auf eine Tabelle die mit FK so aussieht:

0 - Federball

1 - Fussbal

und damit überhaupt keine anderen Daten enthält und enthalten wird. In dem Fall dass sie sich die Liste nicht ändert würde ich ein ENUM Feld verwenden, was aber was anderes ist als ein String.

[Blacks7]

Und das sortieren nach Zahlen ist auf jeden Fall einfacher und schneller als das sortieren nach einen String. Da kann das auch noch so optimiert sein.

Also ich wüsste nur wenige Fälle, in denen man nach dem Primärschlüssel sortiert, da es im Prinzip unsinnig ist:

Wenn man nach dem zuletzt geänderten Datensatz schaut, dann sortiert man nach einem anderen Feld, welches dann meist Update heißt. Oder nach dem neusten, dann meistens nach dem Feld INSERT, da man eh das Datum der Änderung oder der Eintragung haben will.

Es ist vielen DBA's schon passiert, dass der Int überlaufen war, da einfach zu viele kleine Datensätze in der Tabelle waren:

- du hast das z.B. bei Datenloggern, diese senden alle 1 - 5 Minuten den aktuellen Stromverbrauch an eine Schnittstelle, oder die Schnittstelle holt sich in dieser Zeit den aktuellen Verbrauch. Daraus wird dann eine Stromkurve berechnet. Um nun den Verbrauch zu ermitteln und den Service Energieoptimierung anbieten zu können, brauchst du alle Datensätze, da du daraus eine Kurve erstellst.

Ein Datenlogger besitzt 16 Kanäle, welche wiederrum mit verschiedenen Verbrauchsmessern verbunden sind. Da reicht dann Int nach einer Zeit nicht mehr aus.

Ausserdem hast du mit UNIQUE im optimalen Fall einen Eindeutigen Schlüssel in der gesammten Datenbank, es ist unverscheinlich, dass dieser Doppelt vorkommt, im enteffekt egal wieviele Tupels du hast.

Ich merke aber, das viele von euch aus der MySQL Welt kommen, da wird viel mit Int gearbeitet. In MSSQL ist aber als eindeutiger Schlüssel immer ein Unique besser, dafür wurde er ja auch eingeführt.

[Jasper]

Für mich persönlich hört sich das nach Schwachsinn an, aber ich kann mich ja auch irren... Finde jedenfalls keinen Grund, warum ich nicht weiterhin mit IDs in Form von INT arbeiten sollte.

es macht keinen sinn, numerische IDs durch Text-IDs zu ersetzen. allerdings meint dein profi vermutlich etwas anderes: den einsatz von surrogate keys. sollte man einen künstlichen key als primärschlüssel verwenden, wenn ein datensatz durch ein natürliches feld bereits eineindeutig identifiziert wird?

-j

[Blacks7]

sollte man einen künstlichen key als primärschlüssel verwenden, wenn ein datensatz durch ein natürliches feld bereits eineindeutig identifiziert wird?-j

Ich weiß nicht, was an einem Int, welcher einen Nummereischen Wert als Eindeutigkeit festlegt unkünstlich macht! Auf ein Int als PK ist für mich nicht weiter von belang, da er ja auch nur plus 1 zählt. Wenn man daraus eine Rechnungs ID macht, dann sieht die meist auch anders aus und bildet sich nicht aus dem Int wert.

Es ist beides Möglich, dass habe ich auch nicht abgestritten! Aber wenn man eine Eindeutige Eindeutigkeit (1 mal pro Datenbank) haben möchte, dann ist ein Unique besser und wie gesagt unter MS SQL ist ein Unique schneller als ein Bigint.

Für kleine Tabellen (< 1.000.000 Datensatz) ist auch ein Int möglich, aber er stößt irgendwann an seine Grenzen und dass sollte man schon beim Datenbank Modellieren vermeiden. Den nichts ist schwieriger, als eine Große Datenbank, welche seit Jahren läuft, umstellen zu müssen, weil der PK an seine Grenzen läuft!!!

[Guybrush Threepwood]

Nur wie gesagt, Performance ist mit Sicherheit kein Pro für GUIDs.

Nicht? Wie ermittelst du denn bei einem normalen Zahlenwert die nächste ID?

Das ist in den meisten Fällen langsamer als direkt eine guid zu verwenden, vor allem wenn die Anwendung die auf die Datenbank aufsetzt eine Webanwendung ist...

[Guybrush Threepwood]

PS: Hab mich ein wenig undeutlich ausgedrückt

Autoincrement PKs sind natürlich kein Problem bei einfachen Anwendungen wo die Datenhaltung die ganze Zeit direkt in der DB stattfindet. Problematisch wird es aber z.B. wenn es in einem Cache passiert so wie es normalerweise bei ADO.Net stattfindet.

[Jasper]

Es ist beides Möglich, dass habe ich auch nicht abgestritten! Aber wenn man eine Eindeutige Eindeutigkeit (1 mal pro Datenbank) haben möchte, dann ist ein Unique besser und wie gesagt unter MS SQL ist ein Unique schneller als ein Bigint.

was reitest du auf INT rum? ich nehm sequences mit number(38) und habe damit mehr als 10^125 IDs, aber darum geht es hier überhaupt nicht. und was unter MS SQL schneller ist, ist ebenfalls nicht gefragt.

unterhalte dich mal mit DB-Architekten, da ist die frage "surrogate keys oder natürliche keys" eine beliebte streitfrage. und das ist IMHO das, was der profi des OP meinte.

-j

[geloescht_JesterDay]

Also ich wüsste nur wenige Fälle, in denen man nach dem Primärschlüssel sortiert, da es im Prinzip unsinnig ist:

Wenn du den PK als FK benutzt.

Wenn du einen neuen PK brauchst (bzw die DB).

[Jaraz]

INT - 4.294.967.295

BIGINT - 18.446.744.073.709.551.615

Das ein bigint nicht überläuft sollte klar sein.

Wenn ein INT überläuft, kostet ein Wechsel auf BIGINT 16 GB und ein Wechsel auf GUID 48 GB und das nur für die Tabelle und nicht für weitere Verknüpfungen von anderen Tabellen oder dem Index.

Auch wenn Speicher nicht teuer ist, aber gerade bei sehr großen Tabellen würde ich mir sehr genau überlegen ob ich nicht optimale Schlüssellängen nehme.

Ein Wechsel von INT auf BIGINT ist problemlos möglich.

Wechsel von/nach GUID sind sehr problematisch.

GUID hat Vorteile bei verteilten Systemen, aber wie gesagt nicht bei der Performance oder bei großen Tabellen.

Gruß Jaraz

[.vash]

Ich verweise kurz auf diesen Artikel der mir gut gefällt: Surrogatschlüssel - Wikipedia

Auch wenn ein künstlicher PK Nachteile hat wenn ich wenige große Tabellen habe, weiß ich nicht ob es sinnvoll ist einen PK über mehrere Attribute zu bilden wenn ich mit vielen FKs arbeite.

Kann mir vorstellen dass die Diskussion hierüber sehr vom Anwendungsfall der Datenbank abhängt und man der Angemessenheit dem Problem gegenüber den Vorzug geben muss. Eine Grundsatzdiskussion wie sie sich hier andeutet ist wohl überflüssig.

[el_pollo_diablo]

aber um auf das eigentliche thema mit den sportvereinen und deren angebotenen sportarten wieder zurückzukommen...

dein datenbankaufbau ist für diese aufgabenstellung vollkommen ausreichend und kann bedenkenlos so umgesetzt werden.

Jetzt hat aber ein Bekannter sich mit einem "Profi" unterhalten und meinte das wäre totaler Müll, man könnte ja auch, damit die Datenbank "robuster" wird direkt den Namen der Sportart hineinschreiben und könnte sich dadurch nicht so schnell die Datenbank zerschiessen.

natürlich kann man das auch so machen, aber das würde dem grundgedanken beim einsatz relationaler datenbanksysteme widersprechen und bei der späteren anwendung zu gewissen problemen führen...

/sarkasmus ein

man kann sicherlich auch die angebotenen sportarten und deren beschreibung als zusätzliche spalten gleich mit in die tabelle der sportvereine einfügen, aber dann bitte auch gleich noch sämtliche mitglieder und alle relevanten informationen auf die selbe weise mit reinpacken, damit man die daten nicht zerschiesst. so würde ein wahrer profi handeln *kopf schüttel*

/sarkasmus aus

[Jasper]

Kann mir vorstellen dass die Diskussion hierüber sehr vom Anwendungsfall der Datenbank abhängt und man der Angemessenheit dem Problem gegenüber den Vorzug geben muss. Eine Grundsatzdiskussion wie sie sich hier andeutet ist wohl überflüssig.

doppelpluszustimmung.

-j

[geloescht_JesterDay]

Wenn da wirklich etwas übergelaufen ist, dann hat der Planer einfach was falsch gemacht.

Muss mich da etwas korrigieren: Jenachdem wie alt die Anwendung ist, stimmen meine Angaben zu den Zahlenwerten nicht unbedingt.

Ich hab damals nämlich auch noch gelernt, dass ein Int knapp 65000 groß sein kann. Damals war ein Integer eben nur 16bit groß (heute nennt sich das SMALLINT, bei MySQL). An 64bit Integer (BIGINT) hat damals wohl noch kaum einer auch nur im Traum gedacht.

Dennoch muss bei der Planung was schief gelaufen sein, denn das hätte man sich ja leicht ausrechnen können.

Ach ja, wenn es sich um einen 16bit Integer handelte, dann gab es aber mit Sicherheit auch noch keine GUID (MSSQL) als Alternative

[bigpoint]

Hallo Shaun,

text suche ist immer langsamer als zahl suche, deshalb sollte man so gut wie nie texte als PK zu benutzen! Du kannst es aber doch sehr einfach prüfen, erstell noch eine DB mit text PK und vergleiche die Zeiten.

Noch was zu dem DB Design, ist die Tabelle Sportarten_Vereine wirklich nötig?

Du kannst doch in der Tabelle Sportarten PK as Sportverein und Sportart ID zusammen stellen, ist auf jeden fall performanter als join zwischen drei Tabellen

Gruß

bigpoint

[geloescht_JesterDay]

Noch was zu dem DB Design, ist die Tabelle Sportarten_Vereine wirklich nötig?

Ja, da ein Verein ja mehrere Sportarten betreiben kann.