Ähnliche Entitäten in eine Tabelle? (Anfängerfrage)

FestlA

FestlA

Benutzer
Beiträge
6
Moin Moin,

ich habe bis jetzt immer nur kleine Projekte, mit geringer Komplexität erstellt.
Dieses mal muss ich eine etwas größere Anwendung planen, in der unter anderem Geräte inventarisiert werden.
Das können beispielsweise Router, Server, SAN, NAS, Drucker und mehr sein.
Ich würde für jedes Gerät eine eigene Tabelle erstellen. Nun ist allerdings die Frage aufgekommen, ob es nicht eine Möglichkeit gibt, eine Tabelle für viele ähnliche Geräte zu nutzen. Zusätzlich soll der Benutzer später Felder anlegen können, die vorher noch nicht bekannt sind. (z.B. Geräteart)

Gibt es da Empfehlungen, Beispiele oder Regeln, wie man mit solchen Dingen umgeht oder sollte man den Gedanken direkt verwerfen/abschmettern?
Für mich hört sich das nach "Wir sparen uns die Planung und machen einfach alles Flexibel an".

Grüße
af
 
Werbung:
Du meinst sicher pro Gerätegruppe eine Tabelle.

Ja es gibt die Möglichkeit unterschiedliche Felder für ähnliche (oder sogar alle (!)) Geräte zu definieren und damit alle Geräte in eine Tabelle zu speichern.
Du kannst zum einen eine spezielle Tabelle erstellen (Objekt, Feld, Wert), welches du mit deinen Geräten (= Objekt) verknüpfst. (das hat auch einen Fachbegriff, den ich aktuell nicht weiß)
Du kannst aber auch JSON Daten in einem Feld speichern und somit beliebige Feld-Wert Paare oder noch komplexere Informationen speichern.
 
In meinen Augen ist es Irrsinn, für jede Geräteart eine eigene Tabelle zu definieren.

Es gibt ja eine grössere Anzahl an Gemeinsamkeiten, die alle Gerätearten teilen - und wenn ich darüber eine Auswertung machen will oder in der Anwendung darauf zugreifen, dann muss ich jedesmal 20 verschiedene Tabellen berücksichtigen? Alptraum.

Denk an einen Webshop der Elektronik und Computer verkauft. Glaubst Du wirklich, dass nur weil ein Staubsauger andere Eigenschaft besitzt als ein PC (zumindest noch teilweise :D ), dass für hunderte Artikelarten jeweils eigene Tabellen angelegt werden?
 
Deswegen frage ich! ;-)
Könnte mir das vorstellen wie bei der Adressverwaltung am Handy. Da kann ich Felder hinzufügen und entfernen.
Etwa, Geräte-Tabelle mit allgemeinen Felder und dann eine weitere Tabelle für die Eigenschaften, die je nach Gerät unterschiedlich sind. Die könnte der Benutzer dann auch selber anlegen.
Jedes Gerät hat einen Namen, eine Seriennummer, ist einem Standort zugeordnet und hat zusätzliche Eigenschaften, je nach Art.

Geräte
id
Name
Standort_id (Fremdschlüssel)
Seriennummer
Eigenschaften_id (Fremdschlüssel)

Eigenschaften
id
Name
Wert

Ich hoffe das ist verständlich.
 
FestlA schrieb:
Dieses mal muss ich eine etwas größere Anwendung planen, in der unter anderem Geräte inventarisiert werden.
Zum Vergrößern anklicken....

über was für Datenmengen reden wir?

Das können beispielsweise Router, Server, SAN, NAS, Drucker und mehr sein.
Ich würde für jedes Gerät eine eigene Tabelle erstellen.
Zum Vergrößern anklicken....

völlig fail.

Nun ist allerdings die Frage aufgekommen, ob es nicht eine Möglichkeit gibt, eine Tabelle für viele ähnliche Geräte zu nutzen. Zusätzlich soll der Benutzer später Felder anlegen können, die vorher noch nicht bekannt sind. (z.B. Geräteart)
Zum Vergrößern anklicken....

Du willst nicht in größeren Tabellen später dynamisch neue Felder anlegen. Wenn Dein Projekt mit dieser Designentscheidung jetzt startet, ist es bereits jetzt gescheitert.

Ich kommen in weiteren Antworten noch auf die möglichen Optionen zu sprechen...
 
Dukel schrieb:
Du kannst zum einen eine spezielle Tabelle erstellen (Objekt, Feld, Wert), welches du mit deinen Geräten (= Objekt) verknüpfst. (das hat auch einen Fachbegriff, den ich aktuell nicht weiß)
Zum Vergrößern anklicken....

EAV

Du kannst aber auch JSON Daten in einem Feld speichern und somit beliebige Feld-Wert Paare oder noch komplexere Informationen speichern.
Zum Vergrößern anklicken....

ACK. Das ist das, was ich auch empfehlen würde. Und mit passenden Datenbanken kannst Du diese Felder auch indexbasiert - und damit schnell - durchsuchen.
 
FestlA schrieb:
edes Gerät hat einen Namen, eine Seriennummer, ist einem Standort zugeordnet und hat zusätzliche Eigenschaften, je nach Art.

Geräte
id
Name
Standort_id (Fremdschlüssel)
Seriennummer
Eigenschaften_id (Fremdschlüssel)

Eigenschaften
id
Name
Wert

Ich hoffe das ist verständlich.
Zum Vergrößern anklicken....

Ja, ist es. Ich hoffe, Du siehst den Fehler selber.

Falls nein: Du kannst so nur 1 Eigenschaft je Gerät definieren. Mehr nicht.
 
Au, gleich nen Schnellschuss ins Knie!

Geräte
id
Name
Standort_id (Fremdschlüssel)
Seriennummer

Eigenschaften
id
Geräte_id (Fremdschlüssel)
Name
Wert

so schaut es besser aus?!


Danke auch für "EAV", so ein Schlagwort habe ich gesucht!
 
Bin zuerst bei "Die Erste Allgemeine Verunsicherung (EAV) ist eine österreichische Pop-Rock-Band, die 1977 gegründet wurde" gelandet.
Hab mir gedacht, das ist es nicht.
In Verbindung mit Datenbank spuckt Google aber einiges zu lesen aus.
Danke Euch!

Nachtrag: "Größeres Projekt" bedeutet in meinem Fall keine 1000 Geräte. ;-)
 
akretschmer schrieb:
ach wie niedlich ;-)

Unabhängig davon könnte man es auch da schon gleich vernünftig machen und die Nachteile von EAV vermeiden.
Zum Vergrößern anklicken....

Noch bin ich in der komfortablen Situation, dass ich das mit entscheiden kann.
Hast Du ggf. noch einen Tipp, was ich mir anschauen sollte?
Es mangelt am Wissen, nicht an der Motivation es gut zu machen.

Du kannst aber auch JSON Daten in einem Feld speichern und somit beliebige Feld-Wert Paare oder noch komplexere Informationen speichern.
Zum Vergrößern anklicken....
Ich erinnere mich, dass unser Lehrer uns früher davon abgeraten hat. Widerspricht das dann nicht dem eigentlichen System, dass ich ein Feld für einen eindeutigen Wert nutze.
Manchmal ist ggf. die nicht perfekte Lösung (EAV) besser als eine, deren Vorteile man nicht versteht.
 
Wurde schon genannt, Key-Value-Store oder JSON. In PostgreSQL ersteres via HSTORE-Datentyp, zweiteres via JSONB (das B steht für binary). Das mag gegen 'die heilige Kuh' verstoßen, je Feld nur ein Merkmal zu speichern - funktioniert aber super. Achte aber darauf, daß die DB das auch wirklich richtig kann - sprich indexbasiert in solchen Feldern suchen kann.
 
Werbung:
Zurück
Oben