[MySQL] numerical vs. string identifiers

[globe]

n'abend,

aus früheren Zeiten hat sich die Einbildung manifestiert, man müsse Primary Keys (und in der Konsequenz auch die Foreign Keys) mit sequenziellen numerischen Schlüsseln belegen.

Ich habe nun den Fall, dass ich aus Applikationssicht nicht viel mit numerischen Schlüsseln anfangen kann, sondern irgendwelche String Keys benötige.

Auf Grund der alten Einbildung habe ich meine Tabellen nun etwa so gebaut:

table_groups
 - field_id (integer) [PRIMARY]
 - field_key (character) [UNIQUE]
 - field_name (character)
 - …

table_items
 - field_id (integer) [PRIMARY]
 - field_key (character) [UNIQUE]
 - field_group (integer) [FOREIGN: table_groups->field_id]
 - field_name (character)

Die numerischen IDs nutzt hier aber nur die Datenbank für die interne Fremdschlüsselverwaltungsgeschichten. GeJOINt wird auf den Tabellen nicht. Abfragen passieren nach folgenden Schema:

SELECT * FROM table_groups WHERE Wetter = schön;
SELECT * FROM table_items WHERE field_group IN ( *mengeVonGruppenIDs* );

Mir stellt sich die Frage, ob meine Annahmen / Einbildungen seit MySQL 5.0 (InnoDB) vielleicht überholt sein könnten. Also dass man auf die numerischen Schlüssel verzichtet und gleich die String Keys als Primary Keys benutzt.

hat da einer von euch 'ne Ahnung? Tests gefahren? kann was zu sagen?
(Interessant wäre dieses Thema auch auf Basis von PostGreSQL...)

weiterhin schönen abend...

[dedlfix]

Hi!

aus früheren Zeiten hat sich die Einbildung manifestiert, man müsse Primary Keys (und in der Konsequenz auch die Foreign Keys) mit sequenziellen numerischen Schlüsseln belegen.

Sequenziell mussten sie noch nie sein, Lücken waren immer schon "erlaubt". Dass sie keine anderen Typen sein durften, ist mir nicht bekannt. Das Feature auto_increment, das sich großer Beliebtheit erfreut, bedingt aber einen Zahlentyp. Vielleicht war das für deine Assoziation verantwortlich.

Mir stellt sich die Frage, ob meine Annahmen / Einbildungen seit MySQL 5.0 (InnoDB) vielleicht überholt sein könnten.

Bei mir lassen sich MyISAM-Tabellen mit String-PKs problemlos auf InnoDB umstellen.

Lo!

[globe]

n'abend,

Bei mir lassen sich MyISAM-Tabellen mit String-PKs problemlos auf InnoDB umstellen.

Wenn ich mir deine Antwort so auf der Zunge zergehen lasse, durchströmt mich das Gefühl missverstanden worden zu sein…

Dass ich VARCHAR(123) als PrimaryKey einsetzen *kann*, weiss ich. Die Frage war eigentlich mehr in die Richtung "Performance-Einbußen bei StringKeys vs. NumericKeys" gedacht... ;)

weiterhin schönen abend...

[ChrisB]

Hi,

Die Frage war eigentlich mehr in die Richtung "Performance-Einbußen bei StringKeys vs. NumericKeys" gedacht... ;)

Nur mal zwei Google-Fundstellen:
de.comp.datenbanken.mysql: Primärschlüssel: String vs. Integer
SitePoint Forums: String as primary key

MfG ChrisB