Kamikurt

Hallo,

ich könnte eine Anregung gebrauchen, wie ich folgende Frage in einer relationalen DB löse. Für mein Ticketsystem brauche ich zu grunde liegende Infrastruktur, um Alarme und Tickets zu ordnen zu können.

In meiner "Welt" gibt es folgende Elemente:

Server
Hosts
Enclosures
Racks

1. Server ist ins Rack geschraubt

Iteration ist einfach, da ich einen Server in ein Rack setze. Dazu baue ich mir eine Tabelle mit Rackdaten, eine mit Serverdaten und eine Tabelle, in der ich die Beziehungen abbilde.

2. Server ist auf einem Host, der in einem Rack steht

Schon anspruchsvoller. Ich habe drei Tabellen mit Stammdaten (Server, Hosts, Racks). Nun kann ich auch hier einfach sagen: Jeder Server hat einen Host und jeder Host ein Rack - das kann ich über Tabellen und Joins abfangen.

3. Server sind auf dem Host oder im Rack

Da kommen wir dem Problem näher. Ich kann natürlich eine Tabelle bauen, die jedem Server einen Typ zuordnet (z.B. Rack, Host, Enclosure) und eine UUID zur Identifizierung des Ortes. Damit weiß ich, wo der Srever steht. Wenn es nicht direkt das Rack ist sondern z.B. ein Host, weil er eine VM ist, weiß ich damit noch nicht, in welchem Rack er ist. Um das zu erfahren, kann ich eine weitere Abfrage starten, in der ich Host und Enclosure joine und danach Enclosure und Rack.Dazu brauch eich dann aber drei Beziehungstabellen und Abfragen. Oder ich entwickle im Code mehr Logik und versuche, Statements per JOIN über den Typ zu entwickeln, d.h. wenn ich weiß, der Server steht ist ein Blade, brauche ich ja nur das Enclosure ermitteln und das Rack. Ist er eine VM muss ich mehr abfragen.

Soweit läßt sich das alles bauen - skaliert aber irgendwie nicht so recht. Hat jemand ggf. einen Schubs für mich, wie man Tabellen in Beziehung setzt, wenn es unterschiedliche Konstellationen geben kann:

Server - Host - Enclosure - Rack
Server - Rack
Server - Enclosure - Rack

Im Endeffekt will ich - wenn ich einen Server kenne - ermitteln, wie der Server verbaut ist.

Für Tipps oder Gedankenanregungen dankbar
_kami

Mister Ad

akretschmer

Schau mal mein heute gezeigtes rekursives Query. Jedes Objekt hat entweder eine Parent-ID oder NULL, dann ist es 'ganz oben'. Mit solchen rekursiven Abfragen kannst Du in beiden Richtungen wandern, also auch wenn Du das 'Ende' kennst den 'Anfang' finden.


Andreas

nikosch

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

akretschmer

Depends. Es geht um Datenbanken, diese beginnen NICHT mit dem SELECT bla FROM foo, sondern enden an diesem Punkt. Beginnen tun sie mit der konzeptionellen Überlegung, wie man sein Problem in eine Tabellenstruktur bekommt. Sattelt man das Pferd falsch, dann kommen Fragen wie gestern nach dem Durchsuchen von 100 oder mehr Feldern. Dann ist es aber bereits zu spät.

Ich arbeite im Support bei einem Hoster, und sehe quasi täglich die Probleme falscher DB-Strukturen (und der falschen Wahl von MySQL, obwohl es verfügbare Alternativen gibt, die es besser können ...). Nicht mein Problem eigentlich, Kundenproblem, kann mir also egal sein. Aber wenn *hier* Anfänger solche Fragen stellen, sollte man sie IMHO nicht mit einer Default-Antwort wie Deiner verprellen.

Andreas

Kamikurt

Hi all.

@nikosch

Schade, daß Du diesen Eindruck gewonnen hast. Das wollte ich vermeiden. Ggf. siehst Du an dem Eintrag, daß ich bereits ein Ticketsystem geschrieben habe und einen konzeptionellen Anstoß für den Aufbau einer darunter liegenden CMDB gesucht habe - was bedeutet, daß ich schon mal eine Zeile Code geschrieben und ein SQL Statement gebaut habe. GGf. ist es mir auch nicht gelungen, mit meinen Zeilen darzulegen, daß ich im Prinzip bereits eine Lösung habe, aber gehofft habe, daß ggf. jemand was Besseres weiß. Wenn das hier nicht passt, egal - das Netz ist weit, nichts für ungut

@Andreas

Danke Dir, ich geh mal in mich und bastle ein bischen mit rekursiven Ideen, Dein Beitrag hat das erhellt. Wenn ich genug rumgestolpert bin, klopfe ich gern noch mal bei Dir an, wenn das ok ist.

Grüße von
kami

akretschmer

Beachte, daß meine Beispiele ein halbwegs aktuelles PostgreSQL benötigen. Angeblich haben das nicht alle Hoster ... wir aber

Andreas

Kamikurt

Hi alle,

noch ein kurzes Update. Die beste Lösung für mein Problem ist die Verwendung von nested sets (gute Einführung hier: http://www.klempert.de/nested_sets/).

Grüße von
Kami