Wie realisiert ihr folgende beiden Datentypen/Wertebereiche?

[Eddie]

Hallo allerseits,

ein Problem, das bei mir immer wieder auftaucht, ist, dass ich fuer ein Attribut nur bestimmte Werte vorsehe, also den Wertebereich begrenze.
Und ich frage mich jedesmal, wie ich das dann mit MySQL speichern soll :-/

BEISPIEL 1:
  Nicht erweiterbarer Wertebereich, also keine
  weiteren Werte denkbar.

gottheit.beherrschtesElement ENUM('Feuer', 'Wasser', 'Erde', 'Luft') NOT NULL

BEISPIEL 2:
  weitere Werte könnten irgendwann dazu kommen,
  wären dann aber auch wiederum fest vorgegeben:

gottheit.farbe ENUM('abricot', 'rosa') NOT NULL

So wie ich das sehe, habe ich in beiden Fällen folgende Möglichkeiten:

1. so wie im Beispiel einfach als ENUM-Attribut speichern.
      Bei Bedarf (2. Beispiel) die Definition der Spalte erweitern.

2. als text-Wert speichern, also ohne wirklich festen Wertebereich
      Das hätte wohl Vorteile in Sachen Portierbarkeit, aber eigentlich
      will ich ja bei MySQL bleiben.

3. auslagern in eine extra Tabelle, z.B.:
         farbe.id int NOT NULL
      farbe.name ENUM('mausgrau', 'aschfahl') NOT NULL
      um dann in der Tabelle "gottheit" mittels Fremdschlüssel zu verweisen.
      Dann wäre auch sowas denkbar:
         farbe.erklaerung text NOT NULL

Ein Freund von mir favorisiert meistens Variante 3, darum will ich das jetzt mal hinterfragen. Wie seht ihr das, was sind die Vor- und Nachteile?

Danke für eure Hilfe,
Eddie

[Sven Rautenberg]

Moin!

1. so wie im Beispiel einfach als ENUM-Attribut speichern.

2. als text-Wert speichern, also ohne wirklich festen Wertebereich

3. auslagern in eine extra Tabelle, z.B.:

Unveränderliche Werte werden als ENUM gespeichert. Veränderliche Werte als Referenz auf eine separate Listentabelle.

Die Abgrenzung von "unveränderliche Wertebasis" ist allerdings nicht zwingend fest vorgegeben, sondern hängt vom konkreten Anwendungsfall ab.

- Sven Rautenberg

[Tom]

Hello,

Die Abgrenzung von "unveränderliche Wertebasis" ist allerdings nicht zwingend fest vorgegeben, sondern hängt vom konkreten Anwendungsfall ab.

Die fängt schon an zu kriseln, wenn ein Kunde plötzlich sagt:

ach wissen Sie, Herr Schmieder, was Sie uns hier für unsere Filiale in Deutschland gebaut haben, das war eigentlich nur ein Test, ob Sie das können. Sie wissen ja, dass wir auch in Frankreich, Italien, Spanien und Dänemark tätig sind und unsere Zentrale in Groß Britannien sitzt.

Die hätten die Lösung jetzt gerne für alle Standorte, natürlich in Landessprache...

Da war ich aber froh, dass ich kein ENUM benutzt hatte, sondern konsequent darauf geachtet habe, dass interne Schlüssel, Kategorien und Relationen keinesfalls irgendwie sichtbare Datenwerte sind.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Eddie]

Hallo Tom,

verstehe ich dich richtig? Im zweiten Fall (Erweiterbarkeit des Wertebereichs) plädierst du für eine extra Tabelle, und im ersten Fall bleibt es im Grunde mir überlassen?

Martin

[Tom]

Hello,

verstehe ich dich richtig? Im zweiten Fall (Erweiterbarkeit des Wertebereichs) plädierst du für eine extra Tabelle, und im ersten Fall bleibt es im Grunde mir überlassen?

Nein, Du hast mich verkehrt verstanden.

Ich plädiere dafür, von Anfang an Nägel _mit_ Köpfen zu produzieren.

Ich habe hier vor längerer Zeit schon mal eine Funktion zum Thema "enum und HTML-Frontend" gepostet. Die ist wesentlich aufwändiger, als eine Funktion zur Abfrage von Joined-Tabellen

Wenn man dann noch überlegt, dass die Ergänzung einer ausgelagerten Tabelle durch Standardroutinen (inclusive der dazu benötigten Rechteverwaltung) erledigt werden kann, während enums mMn recht kritisch sind bei Änderungen während des laufenden Betreiebes...

Mach Dir das Leben nicht schwer, und nutze die beste Möglichkeit. Die ist mMn eine separate Tabelle für Nachschlagewerte. Für SETs gilt übrigens das Gleiche.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Eddie]

Hallo Tom,

ok, danke dir, ich glaube, jetzt ist es mir etwas klarer!

Eine verwandte Frage hätte ich allerdings doch noch (natuerlich nicht nur an Tom:-).
Wie löst ihr folgendes Problem:

angenommen, ich habe eine Tabelle "Landkarten", die sowohl Länderkarten ("Deutschland") als auch Regionenkarten ("Europa") enthält.
Diese Tabelle lässt sich definitiv nicht auflösen in zwei getrennte Tabellen für Regionen und Länder.

Ausserdem habe ich zwei Tabellen "Länder" und "Regionen", die sich nicht vereinen lassen (auch das geht definitiv nicht).

Die Zuordnung "Karte->dargestelltes_Ziel" mache ich bisher mit einem ENUM _Kartentyp_ (was entsprechend dieses Threads auch eine Hilfstabelle sein könnte). Das sieht dann so aus:

Tabelle Landkarte:
   kartentyp ENUM ('Region', 'Land')
   fk_region int
   fk_country int

Je nach _kartentyp_ ist der entsprechende fk (foreign key) gesetzt, und der andere NULL. Beide referenzieren logischerweise den Primary Key der entsprechenden Tabelle "Länder" oder "Regionen".

Ich finde das schwerfaellig, geht das auch eleganter?

Thanx,
Eddie

[MudGuard]

Hi,

angenommen, ich habe eine Tabelle "Landkarten", die sowohl Länderkarten ("Deutschland") als auch Regionenkarten ("Europa") enthält.
Diese Tabelle lässt sich definitiv nicht auflösen in zwei getrennte Tabellen für Regionen und Länder.

Ausserdem habe ich zwei Tabellen "Länder" und "Regionen", die sich nicht vereinen lassen (auch das geht definitiv nicht).

Die Zuordnung "Karte->dargestelltes_Ziel" mache ich bisher mit einem ENUM _Kartentyp_ (was entsprechend dieses Threads auch eine Hilfstabelle sein könnte). Das sieht dann so aus:

Tabelle Landkarte:
   kartentyp ENUM ('Region', 'Land')
   fk_region int
   fk_country int

Je nach _kartentyp_ ist der entsprechende fk (foreign key) gesetzt, und der andere NULL. Beide referenzieren logischerweise den Primary Key der entsprechenden Tabelle "Länder" oder "Regionen".

Ich würde die Zuordnung andersrum machen. Sprich: die Region-Tabelle enthält eine Spalte kartenid, die Länder-Tabelle ebenfalls.
So könnte eine Karte mehreren Ländern/Regionen zugeordnet sein.

(Stell Dir vor, Du hättest auch noch eine Tabelle Kontinente - dann könnte z.B. dieselbe Karte Australiens sowohl in der Kontinente- als auch in der Länder-Tabelle referenziert werden - oder z.B. für die 3 Länder des Baltikums nur eine einzige Karte existieren, bei Deinem Modell müßte dann die Karte mehrfach in der Karten-Tabelle stehen, jeweils mit anderer Referenz in die Tabelle Länder)

cu,
Andreas