Frage zur Modellierung dynamischer Spalten

Hallo Leute

Ich bin relativ neu im DB-Business und wäre sehr froh, wenn mir jemand
etwas darüber sagen kann, ob sich das folgende Problem nicht einfacher
lösen lässt und ob das so überhaupt sinnvoll ist.

Also, in meiner Applikation benötige ich dynamische Spalten, die zur
Laufzeit der Applikation hinzugefügt und entfernt werden können. Ich
modelliere das so:

CREATE TABLE attribute (
id int(11) NOT NULL auto_increment,
attribute_type_id int(11) default NULL,
object_id int(11) default NULL,
int_value int(11) default NULL,
float_value float default NULL,
string_value text,
datetime_value datetime default NULL,
PRIMARY KEY (id)
);

CREATE TABLE attribute_type (
id int(11) NOT NULL auto_increment,
name text,
type enum('int','float','str','datetime')
default NULL,
PRIMARY KEY (id)
);

CREATE TABLE object (
id int(11) NOT NULL auto_increment,
base_object_id int(11) default NULL,
PRIMARY KEY (id)
);

"attribute_type" stellt die Spalten dar, "attribute" die einzelnen
Zellen und "object" sammelt die eigentlichen Zeilen.

Ich befülle dynamisch meine Attribut-Typen:

INSERT INTO attribute_type (name, type) VALUES ('Jahrgang', 'int'),
('Name', 'str');

.. und einige Daten:

INSERT INTO object () VALUES (),(),();
INSERT INTO attribute (attribute_type_id, object_id, int_value,
string_value) VALUES
(1, 1, 1955, NULL),
(2, 1, NULL, 'Mueller'),
(1, 2, 1967, NULL),
(2, 2, NULL, 'Meier'),
(1, 3, 1855, NULL),
(2, 3, NULL, 'Hansli');

Damit kann ich den gewünschten Select machen:

SELECT object.id, attr_jg.int_value as Jahrgang,
attr_name.string_value as Name
FROM object
LEFT JOIN attribute AS attr_jg ON (object.id =3D attr_jg.object_id
AND attr_jg.attribute_type_id =3D 1)
LEFT JOIN attribute AS attr_name ON (object.id =3D attr_name.object_id
AND attr_name.attribute_type_id =3D 2);

->

+----+----------+---------+
| id | Jahrgang | Name |
+----+----------+---------+
| 1 | 1955 | Mueller |
| 2 | 1967 | Meier |
| 3 | 1855 | Hansli |
+----+----------+---------+

So, und wenn das jetzt nicht schon kompliziert genug ist, benötige ich
zusätzliche Kopien auf diese Objekte. Damit ich nicht immer alle
Attribute kopieren muss (dauert zu lange), arbeite ich mit sowas wie
Referenzen. Trotzdem muss die Möglichkeit gegeben sein, einzelne
Attribute der Kopien zu überschreiben, natürlich ohne das Original zu
veränder. Die Referenz wird über base_object_id realisiert.

Erstelle Referenzen aller Objekte:

INSERT INTO object (base_object_id) VALUES (1),(2),(3);

Überschreiben zweier Attribute:

INSERT INTO attribute (attribute_type_id, object_id, int_value,
string_value) VALUES
(1, 4, 1958, NULL),
(2, 5, NULL, 'Meyer');

Schliesslich, wenn ich nun die Referenzen betrachte (hier bekomme ich
Angst... :-):

SELECT
object.id,
IF(attr_jg.int_value IS NOT NULL, attr_jg.int_value,
base_attr_jg.int_value) as Jahrgang,
IF(attr_name.string_value IS NOT NULL, attr_name.string_value,
base_attr_name.string_value) as Name

FROM object
LEFT JOIN attribute AS attr_jg ON (object.id =3D
attr_jg.object_id AND attr_jg.attribute_type_id =3D
1)
LEFT JOIN attribute AS attr_name ON (object.id =3D
attr_name.object_id AND attr_name.attribute_type_id =3D
2)
LEFT JOIN attribute AS base_attr_jg ON (object.base_object_id =3D
base_attr_jg.object_id AND base_attr_jg.attribute_type_id =3D 1)
LEFT JOIN attribute AS base_attr_name ON (object.base_object_id =3D
base_attr_name.object_id AND base_attr_name.attribute_type_id =3D 2)
WHERE object.id IN (4,5,6);

->

+----+----------+---------+
| id | Jahrgang | Name |
+----+----------+---------+
| 4 | 1958 | Mueller |
| 5 | 1967 | Meyer |
| 6 | 1855 | Hansli |
+----+----------+---------+

Was meint Ihr zu diesem Modell? Geht das irgendwie einfacher? Wird das
auch skalieren? Macht "man" das überhaupt so?

Vielen Dank für Eure Hilfe!

Gruss
Bernhard

Re: Frage zur Modellierung dynamischer Spalten

Bernhard schrieb:
> Hallo Leute
>
> Ich bin relativ neu im DB-Business und wäre sehr froh, wenn mir jemand
> etwas darüber sagen kann, ob sich das folgende Problem nicht einfacher
> lösen lässt und ob das so überhaupt sinnvoll ist.
>
> Also, in meiner Applikation benötige ich dynamische Spalten, die zur
> Laufzeit der Applikation hinzugefügt und entfernt werden können.

Warum?

Re: Frage zur Modellierung dynamischer Spalten

Christian Kirsch wrote:
> Bernhard schrieb:
>
>>Hallo Leute
>>
>>Ich bin relativ neu im DB-Business und wäre sehr froh, wenn mir jemand
>>etwas darüber sagen kann, ob sich das folgende Problem nicht einfacher
>>lösen lässt und ob das so überhaupt sinnvoll ist.
>>
>>Also, in meiner Applikation benötige ich dynamische Spalten, die zur
>>Laufzeit der Applikation hinzugefügt und entfernt werden können.
>
>
> Warum?

Warum nicht, so etwas kommt doch öfter vor.

Re: Frage zur Modellierung dynamischer Spalten

Bernhard wrote:
>
> Was meint Ihr zu diesem Modell? Geht das irgendwie einfacher? Wird das
> auch skalieren? Macht "man" das überhaupt so?
>

Der Ansatz ist zwar schön, aber die Frage ist, ob Deine Objekte wirklich
keine festen Attribute besitzt. Ob das ganze skaliert hängt davon ab,
wieviele Attribute Du nachher hast. Du hast jetzt natürlich noch
keinerlei Indizes angelegt. Bei geeigneter Indexwahl sollte da einiges
möglich sein.
Die Frage der Skalierung hängt dabei natürlich etwas von der Anzahl der
Objekte und Attribute ab. Wenn Du also relativ viele Objekte und wenige
Attribut-Typen hast, solltest Du Dir überlegen ob es dann nicht
performanter ist die fest in das Objekt zu packen.

Ich habe in einer Applikation individuelle Zusatzattribute zu Objekten
realisiert. Das funktioniert eigentlich sehr gut.

Problematisch wird aber Deine Objektreferenzierung sein, da diese einen
erheblichen Aufwand in der Applikation bedeutet.
Das macht die ganzen Abfragen immer etwas unschön, speziell wenn man
dann noch z.B. Sortierungen drauf ansetzt.

An Deiner Stelle würde ich einfach mal so eine Datenbank mit einem
Haufen realistischer Daten füllen und dann mir mal die Performance
anschauen.

Re: Frage zur Modellierung dynamischer Spalten

Stefan Dreyer schrieb:

> Christian Kirsch wrote:
>
>> Bernhard schrieb:
¯¯¯¯¯¯¯¯

Bernhard wer? Realname wäre nett ...

>>> Also, in meiner Applikation benötige ich dynamische Spalten, die zur
>>> Laufzeit der Applikation hinzugefügt und entfernt werden können.
>>
>> Warum?
>
> Warum nicht, so etwas kommt doch öfter vor.

Echt? Erzähl.

Gruß. Claus

Re: Frage zur Modellierung dynamischer Spalten

On 8 Apr., 11:31, Christian Kirsch wrote:
> Bernhard schrieb:
>
> > Hallo Leute
>
> > Ich bin relativ neu im DB-Business und wäre sehr froh, wenn mir jemand=

> > etwas darüber sagen kann, ob sich das folgende Problem nicht einfacher=

> > lösen lässt und ob das so überhaupt sinnvoll ist.
>
> > Also, in meiner Applikation benötige ich dynamische Spalten, die zur
> > Laufzeit der Applikation hinzugefügt und entfernt werden können.
>
> Warum?

Naja, die Frage ist natürlich berechtigt.

Die Anforderung kommt daher, dass wir vom IT-Betrieb relativ lange
Release-Zyklen aufgedrückt bekommen und daher unsere Applikation nur
alle 6 Monate deployen dürfen. Der Benutzer möchte allerdings eine
gewisse Flexibilität in Bezug auf die Verwendung der Daten haben,
weswegen wir sowas wie Plugins eingeführt haben, mit dem der Anwender
recht komplexe Abläufe selber in der Applikation realisieren kann.
Dies erlaubt z.B. auch Skripts, mit denen die Daten manipuliert und
erweitert werden könndn. Damit er dabei möglichst frei ist, muss es
möglich sein, auf den Daten neue Attribute einzuführen.

Ein einfache Beispiel: Ein Teil der Datenbank speichert Kundendaten,
welche nach Geschäftsfeld, Land, Wohnort etc. klassifiert werden.
Falls der Kunde jetzt eine zusätzliche Klassifizierung wünscht (z.B.
nach Kontinent), so kann er sich mittels Plugin diese einfach
zusammenbauen. Das Ergebnis muss dann allerdings irgendwo in einem
Attribut (d.h. eben eine neue Spalte) abgelegt werden.

Die andere Möglichkeit wäre, die Spalten einfach in die Tabelle
einzufügen. Prinzipiell erscheint mir das noch mystischer als das oben
genannte Konzept, liege ich da falsch?

Danke & Gruss
Bernhard Mäder

Re: Frage zur Modellierung dynamischer Spalten

On 8 Apr., 14:25, Stefan Dreyer
wrote:
> Bernhard wrote:
>
> > Was meint Ihr zu diesem Modell? Geht das irgendwie einfacher? Wird das
> > auch skalieren? Macht "man" das überhaupt so?
>
> Der Ansatz ist zwar schön, aber die Frage ist, ob Deine Objekte wirklich=

> keine festen Attribute besitzt. Ob das ganze skaliert hängt davon ab,
> wieviele Attribute Du nachher hast. Du hast jetzt natürlich noch
> keinerlei Indizes angelegt. Bei geeigneter Indexwahl sollte da einiges
> möglich sein.

Klar, die habe ich der Übersichtlichkeit weggelassen.

> Die Frage der Skalierung hängt dabei natürlich etwas von der Anzahl de=
r
> Objekte und Attribute ab. Wenn Du also relativ viele Objekte und wenige
> Attribut-Typen hast, solltest Du Dir überlegen ob es dann nicht
> performanter ist die fest in das Objekt zu packen.

Ich werde so ca. ab 30-50 Attributtypen kommen, die Anzahl Objekte
wird pro Monat (es sind historisierte Daten) auf 20k-30k einpendeln,
also mit der Zeit recht gross werden. Allerdings schaut man sich
später auch nie die Gesamtmenge an, sondern etwa einzelne Jahre.

Ich könnte mir schon vorstellen einzelne Attribute fest in die Tabelle
einzubauen. Das Dumme ist, dass es bei diesen Objekten verschiedene
"Typen" mit unterschiedlichen Attributen gibt, ich müsste also so
etwas wie eine Vererbung bauen, oder aber eine Tabelle mit der
Verinigungsmenge der einzelne Objekte, wobei dann je nach Typ einige
Spalten leer gelassen werde. Und, das wird mir noch nicht reichen, den
Mechanismus der dynamischen Spalten bräuchte ich sowieso, wenn auch
dann nur noch für wenige Spalten. Das wäre für mich aber auch eine
Lösung, die vermutlich performanter ist.

Ich habe aber das Gefühl, dass, wenn ich das Ganze dynamische-Spalte-
Dings sowieso baue, dann macht das die Applikation einfacher, wenn ich
konsequenterweise dabei bleibe. Die Frage ist nur, ob ich dabei nicht
in den (Performance)-Hammer laufe.

>
> Ich habe in einer Applikation individuelle Zusatzattribute zu Objekten
> realisiert. Das funktioniert eigentlich sehr gut.
>
> Problematisch wird aber Deine Objektreferenzierung sein, da diese einen
> erheblichen Aufwand in der Applikation bedeutet.
> Das macht die ganzen Abfragen immer etwas unschön, speziell wenn man
> dann noch z.B. Sortierungen drauf ansetzt.

Ja, das ist vermutlich so. Die meisten Abfragen werden jedoch sowieso
generiert, weswegen ich das verschmerzen könnte. Ich denke mal, mit
Views ginge es auch relativ gut, nur die sind in MySQL glaube ich noch
nicht so brauchbar, oder?

>
> An Deiner Stelle würde ich einfach mal so eine Datenbank mit einem
> Haufen realistischer Daten füllen und dann mir mal die Performance
> anschauen.

Ja, dabei bin ich gerade :-). Das sieht eigentlich soweit gut aus.
Natürlich ist es langsamer als "normale" Spalten (mind. Faktor 2-3),
solange es aber bei wachsender DB bei diesem Faktor bleibt, ist das
für mich ok.

Merci & Gruss
Bernhard Mäder

Re: Frage zur Modellierung dynamischer Spalten

On 8 Apr., 17:38, Claus Reibenstein <4spamerso...@online.de> wrote:
> Stefan Dreyer schrieb:
>
> > Christian Kirsch wrote:
>
> >> Bernhard schrieb:
>
> ¯¯¯¯¯¯¯¯
>
> Bernhard wer? Realname wäre nett ...

Sorry, siehe unten...

>
> >>> Also, in meiner Applikation benötige ich dynamische Spalten, die zur=

> >>> Laufzeit der Applikation hinzugefügt und entfernt werden können.
>
> >> Warum?
>
> > Warum nicht, so etwas kommt doch öfter vor.
>
> Echt? Erzähl.
>
> Gruß. Claus

Kommt für mich darauf an, wie genau man _vor_ der Entwicklung weiss,
was die Applikation machen soll. Bei uns mache ich die Erfahrung, dass
die Leute relativ wenig über ihre Bedürfnisse wissen und diese erst
durch die Benutzung der Applikation formulieren können (und es ist
nicht so, dass wir keine Spez etc. erarbeiten! :-) ). Ausserdem kommen
aus dem täglichen Betrieb auch periodisch neue Analyse-Anforderungen.
Gepaart mit der sehr restriktiven Policy bezüglich Updates (alle 6
Monate, wir sind eben in einer Bank...) hat man da zwei Dinge, die
nicht zueinander passen.

Wir lösen das so, dass wir die Applikation zu einem grossen Teil mit
Skripts erweiterbar machen. Damit das wirklich funktioniert, muss man
aber auch das Datenmodell anpassen können.

Gruss
Bernhard Mäder