Viele enums zusammenfassen

D

David777

Benutzer
Beiträge
13
Hey,
Angenommen ich habe eine Tabelle "Maschinen", in der Maschinen gespeichert werden. Die einzelnen Maschinen sollen durch sehr viele Enumfelder beschreiben werden.
Also z.B.

Maschinen

id: int
maschinennummer : int
standort : varchar
sicherungstyp: enum[ einfach, mittel, sicher, professionell]
treibstoff: enum[rohöl, benzin, gas]
umweltbelastung: enum[hoch, mittel, gering]
.... + sehr viele andere enums.

Ich könnte jetzt entweder jedes enum in einer eigenen Tabelle speichern oder alle in nur einer einzigen Tabelle, wo eben über den "typ" die einzelnen enums getrennt werden.
Mir gefällt die zweite Variante besser und ich will es auch so machen, aber vielleicht habt ihr ja Einwände? :)
 
Werbung:
Ich rate allgemein von Verwendung des ENUM-Datentypes ab und empfehle 'klassische' Nachschlagetabellen, also ganz klassisch Foreign-Key-Constraints.
 
Ich habe nicht vor den enum-Datentyp zu verwenden, sondern es soll so sein:

id: int
maschinennummer : int
standort : varchar
sicherungstyp: enum[ einfach, mittel, sicher, professionell]
treibstoff: enum[rohöl, benzin, gas]
umweltbelastung: enum[hoch, mittel, gering]
.... + sehr viele andere enums.


Wobei ich mit [enum] eine andere Nachschlagtabelle meine, wo die Werte "einfach, mittel, sicher, professionell" gespeichert wären. Frage ist nur, ob ich für jedes Feld eine eigene Tabelle mache, oder eine große Tabelle, wo z.B. "Sicherungstyp" als Typ eine 1 hätte, "Treibstoff" als Typ eine 2 etc.
Also entweder eine große Nachschlagtabelle mit allen feldern oder für sicherungsstyp, treibstoff, umweltbelastung jeweils eine eigene Tabelle?
 
Kannst du näher begründen wieso? Ich müsste in diesem Fall fast 100 einzelne Tabellen erzeugen. Deswegen meine Frage. Wo ist der Nachteil nur eine einzige zu verwenden?
 
Gegenfrage:

wie willst Du die 3 ersteren Tabellen in einer vereinen?

Code: 
test=# create table sicherungstyp(id int primary key, val text);
CREATE TABLE
test=*# create table treibstoff(id int primary key, val text);
CREATE TABLE
test=*# create table umweltbelastung(id int primary key, val text);
CREATE TABLE
test=*# create table david777 (id int primary key, maschinennummer int, standort text, sicherungstyp int references sicherungstyp, treibstoff int references treibstoff, umweltbelastung int references umweltbelastung);
CREATE TABLE
test=*#

Was ist, wenn val kein Text sein soll, sondern ein anderer Datentyp?
 
Nein, also es sind immer nur Texte.
Die Tabelle David777 hätte ich aber nicht so angelegt. Es gäbe hier nur Spalten id, wert und typ.
Also könnte der Inhalt z.B. so aussehen:

id wert typ
1 einfach 1
2 mittel 1
3 sicher 1
4 professionell 1
5 rohöl 2
6 benzin 2
7 gas 2

Um jetzt z.B. später ein Dropdown mit Sicherungstyp zu füllen würde ich dann WHERE typ = 1 holen etc.
 
Mhh... ja darüber hatte ich mir gestern schon den Kopf zerbrochen. Aber meinst du wirklich, dass 100 kleine Tabellen mit jeweils 5 Begriffen die beste Lösung sind? Ich kann es natürlich wirklich so machen...
 
akretschmer schrieb:
ja. Allerdings hast dann unter Umständen 100 Joins - was aber auch nicht schlimm ist.
Zum Vergrößern anklicken....
100 Tabellen? Kann man machen muss man aber nicht.
Das sind typische Klartextauflösungen. Die Werte können problemlos in einer Tabelle abgelegt werden. In einer weiteren Tabelle befinden sich zu den Werten aus der Haupttabelle die Klartextauflösungen, die über den Spaltennamen (und ggf. auch den Tabellennamen sofern es es noch für andere Tabellen nutzbar sein soll) zugreifbar sind.
Die Struktur würde könnte dann in etwa so aussehen:
create table tblklartext (id number primary key,tabelle varchar2(30),feldname varchar2(30),schluessel varchar2(10),text varchar2(4000));

Das macht es sowohl für die Verwaltung als auch für die Entwicklung leichter. Eine Auswahlbox an der Oberfläche z.B. kann damit deutlich leichter erstellt werden, denn der Entwickler muss nur die Klartexttabelle kennen, und nicht die 100 anderen.
 
Werbung:
Zurück
Oben