Zweckmäßigkeit einer Schlüsseltabelle

[Gelöschtes Mitglied 68249]

Hi, ich arbeite an der Erstellung einer Software zur Pflege von Server-Lebenszyklen. Dabei möchte ich meine Daten weitestgehend normalisieren.
Konkret geht es in diesem Fall um Schlüsselwerte. Beispiele dafür wären

• Zustand eines System (GEPLANT, ABGEBAUT, PRODUKTIV,...)
• Auftragsart (AUFBAU,ABBAU,ERWEITERUNG,...)
• EINGANGSART (MAIL,TICKET,...)

Grundsätzlich wäre mein erster Impuls aus allem einen ENUM zu machen und diesen zu verwenden. Aber es gibt auch Schlüsselgruppen, die sich erweitern lassen, ohne dass es zwingend ein neues Release geben muss, z.B. eine neue Eingangsart.
Aus einem anderen Projekt kannte ich das so, dass es dafür zwei Tabellen gab:
Tabelle 1 war für die Schlüsselgruppen verantwortlich, also ID, KURZNAME, LANGNAME in dem Beispiel also System-Status, Auftragsart, Ticketeingang,...
In Tabelle 2 waren dann die Schlüssel, also ID, KURZNAMEN, LANGNAME, SCHLÜSSELGRUPPE.
In der Anwendung gibt man dann für Eingabefelder die Schlüsselgruppe an und das Entity-Objekt speichert sich die Referenz auf die Schlüsseltabelle.

Jetzt bin ich mir zum einen nicht sicher, ob das System heute noch Sinn macht, oder ob es da schon bessere Systeme gibt, oder ihr vielleicht sagt, Finger weg von sowas, mach lieber ein ENUM.

Und wenn das Verfahren Sinn macht, kann ich dann evtl. im JavaCode in der Refferenz schon auf eine Gruppe eingrenzen? Also in etwa so:

@Entity
@Table(name = "OBJ_BLADESERVER")
public class Bladeserver extends BladeRackServer{

    private static final long serialVersionUID = 4270836892791099236L;
    
    @Column(name = "MAC_ADRESSE2")
    private String macAdresse2;
    
    @ManyToOne
    @JoinColumn(name = "STATE", referencedColumnName = "GUID", where="SKeyRange='STATI'" ),
    private SKeyValue status;

    public SKeyValue getStatus() { return status; }
    public String getMacAdresse2() { return macAdresse2; }

    public void setStatus(SKeyValue status) { this.status = status; }
    public void setMacAdresse2(String macAdresse2) { this.macAdresse2 = macAdresse2; }
}

Wäre schön, wenn man das mal ausdiskutieren könnte.

 

[mihe7]

Das hängt davon ab, wie Konstant die Aufzählung und ihre Inhalte sind, die Frage ist ja letztlich "hartkodiert" oder nicht?

 

[Gelöschtes Mitglied 68249]

Jo, genau das ist das Grundproblem. Ich hab da schon einiges Hartcodiert, was ich ursprünglich dynamisch haben wollte, wie z.B. Masken und Datenmodell, weil ich Hartcodiert immer den Weg durch den Lifecycle habe und damit eine ordentliche Definition und Abnahme, aber bei den Schlüsseln gibt es eben solche, die von jetzt auf gleich gebraucht werden und die keine großen Abhängigkeiten haben.

 

[mihe7]

Mal anders: wir haben z. B. Stati, die sind von der Anwendung vorgegeben. Nehmen wir mal einen Vorgangsstatus wie offen -> erledigt -> archiviert. Die haben für die Anwendung eine Bedeutung, weil die Übergänge von der Anwendung realisiert werden: wenn offen und dieses und jenes, dann erledigt. Wenn Status erledigt und Anwender archiviert, dann archiviert. Das sind Konstanten. Die Aufzählung der Stati ändert sich nicht, auch die Bezeichnungen nicht. Wenn sich hieran was ändert, muss sich auch in der Anwendung was ändern. Sprich: enum.

Andererseits könnten wir etwas wie Produktgruppen haben. Die sind für die Anwendung selbst uninteressant. Nach denen wird selektiert usw. Die Wahrscheinlichkeit, dass neue Produktgruppen benötigt werden, ist gegeben. Vielleicht gibts zu den Gruppen eine Beschreibung, die der Anwender ändern können muss. Kurz: die Produktgruppen sind dynamisch, also kein enum.

 

[Gelöschtes Mitglied 68249]

Richtig, länger drüber nachgedacht muss ich dir zustimmen. Stati würden auch hier an Feldfunktionen geknüpft sein. Ich denke ich mach dafür mal ne Tabelle und sprech das mit den Kollegen durch, wie wir das an welcher Stelle regeln wollen. Ich will halt nur den Wust vom Altsystem raus haben, da mussten wir letztes Jahr eine Statusbereinigung machen, weil es da nur Freitextfelder gab und dann gab es so Redundanzen, wie Produktiv, Produktion, Im Einsatz, was am Ende alles dasselbe bedeutet hat, aber durch unterschiedliche Verfahren ist da immer etwas anderes eingetragen worden. Hab ich da die Pflicht ein ENUM oder ein Element einer Liste zu verwenden und lasse am Ende des Tages kein direktes Schreiben auf der DB zu, dann arbeitet ich immer mit einem Java-Objekt und der Feldwert-Prüfung.
Aber danke für die Diskussion, manchmal muss man drüber reden.