nicht angemeldet
"dynamische" Tabelle
hallo,
ich möchte in einer Datenbankanwendung etwas implementieren, von dem ich nicht weis, wie ich es umsetzen kann.
Beispielsituation: Ich habe eine Tabelle mit sagen wir 20 Feldern und unzähligen Datensätzen, welche jeweils einen Adresseintrag darstellen.
Auf die Tabelle greifen mehrere Benutzer zu, der seine eigenen Adressen speichert. Jeder Benutzer kann individuelle Felder anlegen, z.B. wenn jemand zur Adresse noch die Schuhgrösse und Augenabstand speichern möchte. Ein anderer Benutzer braucht diese aber nicht, sondern hat eigene induviduelle Felder.
Das Problem: Wie implementiere ich diese individuellen Felder?
-
Wenn ich für jedes Feld eines Benutzers tatsächlich ein Feld in dieser Datenbank anlege, bleibt es jeweils bei den Einträgen von anderen Benutzern leer und die Tabelle wird riesig.
-
Wenn ich für jedes Feld eine Extratabelle anlege und die Einträge mit der Haupttabelle verknüpfe, entstehen sehr viele Tabellen.
Gibt es eine Technik, mit der so etwas einfacher und auch Ressourcensparend umgesetzt werden kann? Ich weis nicht so recht, nach was ich suchen muss und bin froh um jeden Input.
-
Hello,
verwende folgende Tabellen:
Feld
-----------------
1 | Schuhgröße
2 | Augenfarbe
...Benutzer
----------------------
1 | Max | MustermannBenutzerFelder
------------------
1 | 1 | 42
1 | 2 | braunDarüber, ob man Max und Mustermann in der Benutzertabelle ablegen sollte, kann man streiten. Man kann es auch volldynamisch machen und alle Werte freistellen.
MfG
Rouven--
-------------------
Unser Problem ist, dass wir eine Demokratie entwickelt haben, was nicht immer der richtige Weg ist -- Bernie Ecclestone zu den lästigen Diskussionen um Regeländerungen in der Formel 1-
Hello,
verwende folgende Tabellen:
vielen Dank, das sieht logisch aus. Nur der Datentyp muss dann bei allen Feldern gleich sein, aber das wäre wohl machbar.
-
Hi,
Nur der Datentyp muss dann bei allen Feldern gleich sein
Nein, muss es nicht zwingend.
Du kannst in der Wertetabelle mehrere Spalten mit verschiedenen Werttypen (Text, Numerisch, ...) machen. Und der Tabelle, in welcher die "dynamischen Attribute" definiert sind, der gibst du eine weitere Spalte namens "Datentyp". Dann kannst du in der Logik aussenrum um die DB das notwendige SQL dynamisch zusammenbauen.
Cheers, Frank
-
Du kannst in der Wertetabelle mehrere Spalten mit verschiedenen Werttypen (Text, Numerisch, ...) machen. Und der Tabelle, in welcher die "dynamischen Attribute" definiert sind, der gibst du eine weitere Spalte namens "Datentyp". Dann kannst du in der Logik aussenrum um die DB das notwendige SQL dynamisch zusammenbauen.
Das stimmt natürlich, da hast du recht. Oder für jeden Datentyp eine eigene Tabelle anlegen, damit spare ich mir den Speicherplatz für die leeren Felder.
-
Hello,
Das stimmt natürlich, da hast du recht. Oder für jeden Datentyp eine eigene Tabelle anlegen, damit spare ich mir den Speicherplatz für die leeren Felder.
dann schrei aber hinterher nicht, wenn deine Performance in den Keller geht oder du den Überblick im Tabellendschungel verlierst. IMHO eine schlechte Idee...
MfG
Rouven--
-------------------
Unser Problem ist, dass wir eine Demokratie entwickelt haben, was nicht immer der richtige Weg ist -- Bernie Ecclestone zu den lästigen Diskussionen um Regeländerungen in der Formel 1-
Hello,
Das stimmt natürlich, da hast du recht. Oder für jeden Datentyp eine eigene Tabelle anlegen, damit spare ich mir den Speicherplatz für die leeren Felder.
dann schrei aber hinterher nicht, wenn deine Performance in den Keller geht oder du den Überblick im Tabellendschungel verlierst. IMHO eine schlechte Idee...Das ist das Problem.
Bis heute fiel mir dazu seit 20 Jahren nichts besseres ein, als ein Variant-Feld zu benutzen, die Daten für die Sortierbarkeit dann ihrem Typ entsprechend mit führenden Leerzeichen oder Nullen aufzufüllen oder sont irgendeinen Blödsinn.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
-
-
Hello Frank,
Nur der Datentyp muss dann bei allen Feldern gleich sein
Nein, muss es nicht zwingend.
Du kannst in der Wertetabelle mehrere Spalten mit verschiedenen Werttypen (Text, Numerisch, ...) machen. Und der Tabelle, in welcher die "dynamischen Attribute" definiert sind, der gibst du eine weitere Spalte namens "Datentyp". Dann kannst du in der Logik aussenrum um die DB das notwendige SQL dynamisch zusammenbauen.
In der Datentabelle (oder _den_ Datentabellen) für die Eigenschaften hat der Datentypbezeichner nichts zu suchen. Der gehört in die Eigenschaftenklassen, da er an sie gebunden ist.
Und für jeden zugelassenen Datentyp muss dann eine eigene Eigenschaftentabelle gebaut werden, allerdings nur aus der Sicht des "Platzsparers". Mit Normalisierung hat das (leider) nichts zu tun, denn hier scheitern die Modelle dafür mMn alle.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hi,
ich schrieb ja auch "in welcher die "dynamischen Attribute" definiert sind" und nicht "wo die werte drin stehen".
Cheers, Frank
-
Hello,
ich schrieb ja auch "in welcher die "dynamischen Attribute" definiert sind" und nicht "wo die werte drin stehen".
Ja, wo du's jetzt sagst ;-)
Aber das Problem ist so alt, wie die Datenbanken, glaube ich.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
-
-
-
-
-
yo,
Das Problem: Wie implementiere ich diese individuellen Felder?
nicht in der gleichen tabelle, diese sollte nur die nicht-dynamischen attribute (spalten) enthalten. die dynamischen lagerst du in zwei extra tabellen aus. die eine tabelle (Dynamische_Attribute) besteht aus sagen ir mal 2 spalten, einer id und einen einer spalte, die die unterschiedlichen dynamischen attribute aufnimmt, zum beispiel schugröße.
die zweite tabelle ist die Beziehungstabelle zwischen deiner "Haupttabelle" und der tabelle mit den dynamischen attributen, sprich es handelt sich da um eine n:m beziehung. so kann jeder benutzer seine schugröße angeben, wenn er will, muss es aber nicht. die beziehungstabelle enthält neben den beiden fremdschlüssel auch noch eine spalte für die werte, zum beispiel 42 für die schugröße
Ilja
-
Hello,
zum beispiel 42 für die schugröße
MfG
Rouven--
-------------------
Unser Problem ist, dass wir eine Demokratie entwickelt haben, was nicht immer der richtige Weg ist -- Bernie Ecclestone zu den lästigen Diskussionen um Regeländerungen in der Formel 1-
yo,
42 scheint ein standarwert zu sein.... ;-)
Ilja
-
42 scheint ein standarwert zu sein.... ;-)
Allerdings :-)
vielen Dank für deine Antwort, ich versuche das mal umzusetzen.
-
Hello,
42 scheint ein standarwert zu sein.... ;-)
Wie war doch gleich die Frage?
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
-
-
Hello Ilja,
nicht in der gleichen tabelle, diese sollte nur die nicht-dynamischen attribute (spalten) enthalten. die dynamischen lagerst du in zwei extra tabellen aus. die eine tabelle (Dynamische_Attribute) besteht aus sagen ir mal 2 spalten, einer id und einen einer spalte, die die unterschiedlichen dynamischen attribute aufnimmt, zum beispiel schugröße.
die zweite tabelle ist die Beziehungstabelle zwischen deiner "Haupttabelle" und der tabelle mit den dynamischen attributen, sprich es handelt sich da um eine n:m beziehung. so kann jeder benutzer seine schugröße angeben, wenn er will, muss es aber nicht. die beziehungstabelle enthält neben den beiden fremdschlüssel auch noch eine spalte für die werte, zum beispiel 42 für die schugröße
Da ist es wieder, mein altes Problem.
Wie berücksichtigt man bei einer varianten Eigenschaftenzuordnung die Typgerechtigkeit der Eigensschaft?
Berücksichtigt werden soll i.d.R. in der Praxis für den User die Eigenschaftenklasse. Das ist kein Problem, denn steht in einer zusätzlichen Tabelle. Un wenn eine Klasse fehlt, kann sie angelegt werden (durch einen berechtigen User). In der Eigenschaftenklasse muss dann auch der Datentyp der Eigenschaft festgelegt werden (und die Wertigkeit?). Nun müsste man ja je nach Datentyp die Verknüpfung in eine andere Tabelle vornehmen.
Oder wie löst man sowas auf?
Nur mit Variant-Feldern zu arbeiten ist ja eigentlich nicht sauber.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
yo,
Wie berücksichtigt man bei einer varianten Eigenschaftenzuordnung die Typgerechtigkeit der Eigensschaft?
mit der obermenge.
Nun müsste man ja je nach Datentyp die Verknüpfung in eine andere Tabelle vornehmen.
zuviel aufwand.
Nur mit Variant-Feldern zu arbeiten ist ja eigentlich nicht sauber.
sauber ist eine frage der perspektive. man muss sich vor augen halten, dass rdbms nicht für dynamik ausgelegt sind. man definiert einen status quo und der ist es dann. spätere änderungen des datenbank-designs sind in aller regel sehr "häßlich". oder mit anderen worten, die realität kann dynamischer sein als dein datenbank-design es zulässt.
Um nun wenigstens ein paar eigenschaften dynamisch zu gestalten benutzt man diesen kunstgriff, sie auszulagern. sicherlich ist das mit dem datentyp nicht so elegant, aber praktisch und meiner meinung nach der beste kompromiss. und ein kompromiss wird es immer sein.
in aller regel meckern dann meistens auch nur die programmierer aus der oo-welt, so wie meine entwickler auf der arbeit. die erzählen mir auch immer, wie wichtig doch ihre java umgebung ist und "meine" datenbank nur ein anhängsel. aber wenn die application dann wieder mal die daten "versaut" hat, dann kennen sie mich wieder..... ;-)
Ilja
-
-