SQL Tabellenmodellierung

[JenZor]

Zuerst dachte ich ich versuche mal ORM umzusetzen,
aber die Zeit mir diesen Luxus zu gönnen, habe ich nicht mehr.

Ich werde mir jetzt ne kleine Funktion tüfteln, die mir eine bestehende Struktur in eine DB schreibt und Schicht im Schacht.



Dazu muss ich mir das DB Schema selbst modellieren. Meine letzte Tabellenmodellierung ist allerdings schon ein paar Tage her.


Folgendes ist gegeben:

1 LPAR hat N CPUs
1 LPAR hat N Festplatten
1 LPAR hat N NetzwerkControler

1 CPU hat N MessdatenCPU
1 Festplatte hat N MessdatenHDD
1 NetzwerkControler hat N MessdatenNWC
1 LPAR hat N MessdatenLPAR
1 LPAR hat N MessdatenSpeicher

Eine LPAR wird über LPAR.ID identifiziert.
Eine Komponente ( CPU / HDD / NetzControler ) über die Kombination (Komponente.ID, LPAR.ID)
Eine Messdatei über die Kombination (Datum, Komponente.ID)


Wenn ich das jetzt so aufbaue, dann habe ich einen mehrstelligen Schlüssel bei den Komponenten und den Messdaten.

Das wird am Ende unschön, da ich den doppelten Schlüssel "mitnehmen" muss bis ganz runter.

Die Tabellen sähen dann am Beispiel so aus:


LPAR( ID , SerialNr, ...)

CPU( ID , LPAR_ID -> LPAR.ID , ...)

STR_CPU( DATE , CPU_ID -> CPU.ID , LPAR_ID -> CPU.LPAR_ID , ... )


Das ist meiner Meinung nach aber iwie totaler Crap. Fremdschlüssel als Primärschlüssen zu verwenden... , oder?

Ich könnte auch immer eine eigenständige ID / Tabelle nehmen, da ich diese ID aber zur Laufzeit nicht habe , müsste ich jedes Mal testen, ob es bereits eine CPU/HDD/NWC/Messdatei/.. mit den gegeben Werten gibt und das kostet auch Zeit ...

Das wäre dann iwas mit:

SELECT * FROM CPU
WHERE  ID = ... AND LPAR_ID = ...;

Und dann über

Boolean isAlreadyInsert = query.getResult().getSize() > 0;

bestimmen ob der Datensatz bereits in der DB ist.


Gibt es da nichts elegantes?
Wie gesagt das letzte mal, dass ich was mit DBs zu tun hatte ist schon etwas her




Danke schonmal für die Hilfe


Gruß

J.


P.S. der Smiley im Titel ist ausversehen mit reingerutscht

 

[g0l3m]

Ich habe eine Anwendung im produktiven Betrieb, die bzgl. der Komplexität der Referenzierungen ähnlich aufgebaut ist. Du wirst nicht umhinkommen, die Fremdschlüssel für die Meßwerte "mitzunehmen", da Du ja eindeutige Referenzen auf Komponente und LPAR (was ist das?) brauchst. Allerdings würde ich den Meßwerten wohl in jedem Fall eine eigene Id als Primärschlüssel geben.

Das mit der Laufzeit und dem SELECT verstehe ich nicht: Willst Du was mit den Daten machen, musst Du sie doch in jedem Fall aus der DB holen?! Allerdings kannst Du über JOINs mehrere Tabellen abfragen, so dass Du z. B. dem n + 1 Problem aus dem Weg gehst und für LPAR, Komponenten und Messwerte nur einen Query brauchst.

Irgendwann mit steigender Datenmenge kostet es wirklich Zeit, bei vielen Daten wirst Du ohnehin nicht umhin kommen, Dich mit manuellen Queries und Caching über Denormalisierung zu beschäftigen. Das ist meiner Meinung aber erst der 2. Schritt, wenn die konkreten Probleme feststehen, z. B. teure Hierarchieabfragen oder -inserts.

Ich würde mir an Deiner Stelle einen der populären ORMs suchen, der Dich bei den Queries und Assoziationen der Klassen untereinander unterstützt. Wenn es dann handgemacht sein muss, kann man immer noch auf DB Query-Strings zurückgreifen. Aber den ganzen Basiskram muss man nicht mehr per Hand machen, zumal man durch den ORM auch gezwungen ist, sich innerhalb eines gewissen Rahmens zu bewegen, was nicht unbedingt das schlechteste ist, wenn man nicht ständig mit der DB Konsole kuschelt...

 

[JenZor]

Danke erstmal für die Antwort.

1. LPAR = Akronym für Logisch Partition.

2. Ich habe mich versucht mit ORM auseinander zu setzen aber ich steige da nicht durch. Im Netz finde ich immer wieder nette Tutorials die auch in einem Satz beschrieben werden könnten: "Lade dir Plugin/JAR xyz von <Link> und nutze es!"

Ich bin steige da absolut nicht durch.
Und bildlich gesprochen suche ich einen Schraubenschlüssel und diese ORM APIs scheinen eher sowas wie 1500-teilige Werkzaugkoffer zu sein. Das wäre für das kleine Projekt eher overkill und ich kann nicht nochmehr Zeit verlieren.


Grobe Umreißung von dem was ich vorhabe:

Ich bekomme täglich eine Serverliste, die durchlaufe ich, baue ne Verbindung auf, ziehe mir eine *.nmon (Performancedaten) Datei und lese die über einen Parser in ein und schreibe sie in eine vorgesehene DB (alles automatisiert).

Über eine zweite Application will ich diese Daten auf Bedarf strukturiert z.B. im Browser ausgeben.




Der Parser funktioniert wunderbar, jetzt muss ich die Daten in die DB schreiben.

Im Prinzip sowas wie:

public intoDB(lpar) {

  try { insertLparHeader() }  // LPAR ist noch nicht in DB
  catch { updateLparHeader() } // LPAR ist bereits in DB

  // Beispiel für CPU:

  for(CPU c : lpar.getCPUList()) {
    
    try { insertCPUHeader() } // CPU ist noch nicht in DB
    catch { updateCPUHeader() } // CPU ist bereits in DB

    for(Data d : c.getData()) {
      
      try { insertData() } // Data noch nicht in DB
      catch { updateData() } // Data bereits in DB
    }

  }

Den CPU Block dann nochmal für HDD und NWControler sowie 2 zur LPAR gehörende List<Data>

Überschaubar und bei 1500 Datensätze / Tag für je 2-4 CPU, 2-4 NWControler und ~10 HDDs und die LPAR


Gruß

J.

 

[g0l3m]

Den Konzeptcode, den Du gepostet hast, ist genau das, was Dir ein ORM abnimmt: Er stellt Dir die Methoden zum CRUDen der Objekte und deren Assoziationen zur Verfügung, so dass man sich von links (LPAR) nach rechts (CPU => DATA) durchhangeln kann.

Ob sich der Lernaufwand lohnt, kannst nur Du entscheiden. Ich kann mir nicht vorstellen, dass es für Java keinen leichtgewichtigen ORM, z. B. für das ActiveRecord Pattern, gibt: http://en.wikipedia.org/wiki/Active_record_pattern#Java

Wenn Du es selbst schreiben willst, dann würde ich zumindest nach Unterstützung für die Query Generierung des AST in Form einer Bibliothek suchen.

 

[JenZor]

Ich habe wie gesagt versucht mich in die ORMs reinzuarbeiten. Von Hibernate über EclipseLink bis OpenJPA... iwie war das alles immer sehr schwammig und hat nicht hingehauen.
Da ich eine Deadline für das Projekt habe und ich schon ne Woche mit dem ORM verbracht habe ohne Ergebnis ist der einzig logische Schluss: wenn es nicht über eine neue Methode geht, mach es auf eine die Bekannte Art.

Ich weiß, dass ORM mir das alles abnimmt und sogar noch mehr macht, aber ich kriegs nicht hin und es bringt nichts mich damit weiter zu beschäftigen, wenn an Tag X was da sein muss, ob es dann performant ist, ist ja erstmal banane, aber es muss funktionieren. Danach kann man es zur Not überarbeiten und solche netten frameworks reinbauen... die Zeit habe ich jetzt leider nicht mehr.


Du hattest mir aber die Frage nach den Fremdschlüsseln als Primärschlüssel schon knapp beantwortet.

Nochmal im Detail:

Wenn ich einen zusammengesetzen Schlüssel habe auf dem per Fremdschlüssel referenziert wird muss ich den gesamten Schlüssel auch in der Tabelle mitnehmen?

Tab1(PK1, PK2, Attr1, Attr2,..)
Tab2(ID, FK -> Tab1.PK1, FK2 -> Tab1.PK2, ...)

Wie ich eingangs schon beschrieben habe.


unschön, aber es klappt wenigstens.. naja gut ... back to the roots..


Danke erstmal!

Gruß

J.