MySQL: ENUM Spalte oder Zuordnungstabelle

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Werte Foren Gemeinde,

ich beschäftige mich seit kurzem mit dem Design von MySQL Datenbanken. Hierzu habe ich eine Frage. Ist folgendes Design „gut“, oder könnte/sollte man die Zuordnungstabelle durch eine entsprechende ENUM Spalte in der Haupttabelle (Personen) einsparen?

**Personen**
| Peronene\_ID | Name | Haarfarbe\_ID |
--------------------------------------
| 1 | Gabi | 2 |
| 2 | Moni | 3 |
| 3 | Dani | 2 |
.....


**Haarfarbe**
| Haarfarbe\_ID | Haarfarbe\_Name |
---------------------------------
| 1 | blond |
| 2 | brünett |
| 3 | schwarz |

Und wie sieht es im Fall von m:n Beziehungen aus? Sind auch hier ENUM Spalten möglich oder gar die bessere Wahl?

**Personen**
| Peronene\_ID | Name | Haarfarbe\_ID |
--------------------------------------
| 1 | Gabi | 2 |
| 2 | Moni | 3 |
| 3 | Dani | 2 |
.....


**Hobbies**
| Hobby\_ID | Hobby\_Name |
-----------------------------
| 1 | tanzen |
| 2 | singen |
| 3 | schwimmen |

**Personen\_Hobbies**
| Personen\_ID | Hobby\_ID |
---------------------------
| 1 | 1 |
| 1 | 3 |
| 2 | 2 |
| 2 | 3 |
| 3 | 2 |

Schöne Grüße, Sax

#2

Moin, Sax,

ENUM ist immer dann angebracht, wenn der Wertebereich von vornherein bekannt ist, sich nie ändern wird und nur an einer Stelle gebraucht wird.

Gruß Ralf

#3

Hallo Ralf,

das bedeutet dann wohl, im Jahr 2003 hätte es z.B. keinen Sinn gemacht folgende Zuordnungstabelle durch eine ENUM Spalte zu ersetzen, da neue Geräteklassen (Netbook, Tablet) möglich bzw. wahrscheinlich sind.

**Geraeteklasse**
| Geraeteklasse\_ID | Geraeteklasse\_Name |
-----------------------------------------
| 1 | Notebook |
| 2 | PC |
#4

Ich habe noch eine Frage zu den von mir geposteten Tabellen. Macht es Sinn in der Tabelle „Personen“ die Spalte „Haarfarbe_ID“ als Fremdschlüssel zu kennzeichnen? Wie sieht es mit der Tabelle „Personen_Hobbies“ aus? Benötigt diese einen Primärschlüssel?

#5

Hi Sax,

als Fremdschlüssel zu kennzeichnen?

ich wüsste nicht einmal, wie das geht (SQL seit 1986).

Wie sieht es mit der Tabelle „Personen_Hobbies“ aus?
Benötigt diese einen Primärschlüssel?

Ich würde mir darum gar keine Gedanken machen. Erstmal schadet er nicht, und später bist Du vielleicht mal froh drum.

Ganz blödes Beispiel: Du baust eine Anwendung, in der eine Farbe den schönen Namen „rot“ trägt. Irgendwann merkt das der Coiffeut und besteht darauf, dass sie „kamille-marille“ heißen muss. Wenn Dein Programm die Bezeichnungen als Such- oder Verknüpfungswert benutz, bist Du gekniffen, andernfalls kannst Du ihn kreativ sein lassen, wie er mag.

Gruß Ralf

#6

Danke für deinen Post.

ich wüsste nicht einmal, wie das geht (SQL seit 1986).

Laut meinem Buch mit dem Schlüsselwort „references“ (anscheinend nur bei InnoDB Tabellen). Warum und wann man das machen sollte, verrät mein Buch aber leider nicht.

Ganz blödes Beispiel: Du baust eine Anwendung, in der eine
Farbe den schönen Namen „rot“ trägt. Irgendwann merkt das der
Coiffeut und besteht darauf, dass sie „kamille-marille“ heißen
muss. Wenn Dein Programm die Bezeichnungen als Such- oder
Verknüpfungswert benutz, bist Du gekniffen, andernfalls kannst
Du ihn kreativ sein lassen, wie er mag.

Die Spalte „Haarfarbe_ID“ habe ich in der Tabelle „Haarfarbe“ als Primärschlüssel festegelegt. Als Suchwert benutze ich die ID. Das erscheint mir so auch logisch. Die Tabelle „Personen_Hobbies“ besteht aber aus zwei Fremdschlüssel, ist hier ein zusätzlicher Primärschlüssel sinnvoll?

#7

Hi Sax,

Laut meinem Buch mit dem Schlüsselwort „references“

so geht’s, wenn man jahrzehntelang nur noch mit grafischen Oberflächen arbeitet, die Beziehungen per drag&drop aufbaut und den Blechdeppen dann machen lässt :smile:))

Die references-Klausel ist natürlich das Α und Ω der Beziehung, genau da wird festgelegt, welche Gestalt sie haben soll.

Warum und wann man das
machen sollte, verrät mein Buch aber leider nicht.

Daran erkennt das DBMS, dass zB im referierenden Feld nur Einträge sein dürfen, die im referierten Feld existieren.

Die Tabelle „Personen_Hobbies“ besteht aber aus zwei Fremdschlüssel,
ist hier ein zusätzlicher Primärschlüssel sinnvoll?

Ich mach es andersrum, weil damit Verknüpfungen einfacher abzufragen sind: Solche Tabellen bekommen einen Autowert als Schlüssel, und auf den beiden Fremdschlüsselattributen liegt ein eindeutiger Index.

Gruß Ralf