Gruende fuer Primary Key als varchar

Hallo,
koennte es Gruende geben, beim Datenmodell Primary Keys als varchars
anzulegen und nicht als Integer-Werte?

Ein (konstruierter) Grund koennte sein, dass man sich eine Unique ID
erzeugt, diese als Primary Key verwendet und dann vor dem Erzeugen eines
neuen Datensatzes bereits dessen Primary Key/ID kennt.
(Und sich einem Befehlt zum holen dieser ID spart.)

Wie sind Eure pauschalen Meinungen/Schaetzungen zu
Performance-Unterschieden bei "vielen Datensaetzen?

Danke. mfg. klaus.

Re: Gruende fuer Primary Key als varchar

Klaus Herzberg schrieb:
> koennte es Gruende geben, beim Datenmodell Primary Keys als varchars
> anzulegen und nicht als Integer-Werte?

Wenn das Feld eines ist, das angezeigt wird, ist es (meistens) auch
eines, das sich ändern kann.
Der Primary Key wird aber gerne in anderen Tabellen zum Herstellen von
Beziehungen verwendet, man müsste bei einer Änderung auch alle
Datensätze korrigieren, die den Text als Fremdschlüssel verwenden. Das
ist entweder aufwändig (wenn man Transaktionen hat) oder unsicher (wenn
man sie nicht hat und der Datenbankserver fällt aus irgendeinem Grund
aus, nachdem die Hälfte der Datensätze geändert wurde, und schon zeigen
bei einer Hälfte der Datensätze die Verknüpfungen ins Leere).

Performancetechnisch sind fortlaufend vergebene INT-Schlüssel ebenfalls
günstiger als VARCHAR-Schlüssel: Beim Vergleichen muss die Datenbank
mehr Bytes anschauen, um festzustellen, ob sie beim richtigen Satz ist
oder nicht, und auch die Datenstrukturen sind für Strings aufwändiger
als für Integers (einfach, weil die Länge bei Strings variieren kann).
Außerdem wissen die Datenbankhersteller, dass die meisten Primary Keys
Integers sind, und wann immer sie zwischen "funktioniert für Integer und
String gleich schlecht" und "funktioniert für Integer gut, für String
aber etwas schlechter" haben, werden sie sich für den zweiten Fall
entscheiden.
Größeren Einfluss hat allerdings, dass man die Queries und Indexe
richtig gestaltet.

In der Praxis ist der erste Grund meistens das KO-Kriterium.

> Ein (konstruierter) Grund koennte sein, dass man sich eine Unique ID
> erzeugt, diese als Primary Key verwendet und dann vor dem Erzeugen eines
> neuen Datensatzes bereits dessen Primary Key/ID kennt.
> (Und sich einem Befehlt zum holen dieser ID spart.)

Ich glaube nicht, dass das eine Rolle spielt.
Aber das war ja auch ein konstruierter Grund :-)

> Wie sind Eure pauschalen Meinungen/Schaetzungen zu
> Performance-Unterschieden bei "vielen Datensaetzen?

Vermutlich nur mit Messungen feststellbar.
Relevant nur, wenn man ein großes Budget für Performancesteigerung hat.
(Bestelldaten eines Konzerns oder so, wo dann das nächstgrößere
Rechenzentrum ein paar Millionen kostet, die Entwicklerzeit hingegen nur
ein paar Zehntausend.)

Grüße
Jo