Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

Viele enums zusammenfassen

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von David777, 28 Juli 2016.

  1. David777

    David777 Benutzer

    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? :)
     
  2. akretschmer

    akretschmer Datenbank-Guru

    Ich rate allgemein von Verwendung des ENUM-Datentypes ab und empfehle 'klassische' Nachschlagetabellen, also ganz klassisch Foreign-Key-Constraints.
     
  3. akretschmer

    akretschmer Datenbank-Guru

    wie genau meinst du das?
     
  4. David777

    David777 Benutzer

    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?
     
  5. akretschmer

    akretschmer Datenbank-Guru

    jeweisl eine eigene Tabelle.
     
  6. David777

    David777 Benutzer

    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?
     
  7. akretschmer

    akretschmer Datenbank-Guru

    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?
     
  8. David777

    David777 Benutzer

    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.
     
  9. akretschmer

    akretschmer Datenbank-Guru

    wie willst du referentielle Integrität sichern?
     
  10. David777

    David777 Benutzer

    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...
     
  11. akretschmer

    akretschmer Datenbank-Guru

    ja. Allerdings hast dann unter Umständen 100 Joins - was aber auch nicht schlimm ist.
     
  12. drdimitri

    drdimitri Datenbank-Guru

    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.
     
  13. ukulele

    ukulele Datenbank-Guru

    100 Joins sind es aber trotzdem, oder habe ich was verpasst?

    Lösen würde ich das auch über eine Tabelle.
     
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden