Objekteigenschaften in Datenbank speichern

[dedlfix]

Tach!

Oder lässt sich ein Objekt auch eleganter speichern? Also dass automatisch alle Objekteigenschaften auf die entsprechenden Tabellenfelder gemappt werden?

Undefiniert viele Eigenschaften sollte man nicht in Feldern speichern.

Wenn es denn undefiniert viele sind. Aber undefiniert viele würde ich auch nicht als Eigenschaften von Objekten modellieren wollen. Undefinierte Werte ist besser in Key-Value-Arrays (assoziative Arrays, Dictionarys) aufgehoben. Der Unterschied ist, dass die Namen von Objekteigenschaften Identifier sind, die genau bekannt sind, und damit sind sie auch vom Code direkt ansprechbar. Ein Array ist eine Sammlung mit praktisch unbegrenzter Anzahl von Elementen, deren Keys aber auch zur Entwicklungszeit unbekannt sein können. Ja, Objekt in PHP können ebenfalls zur Laufzeit beliebig viele Eigenschaften dazubekommen, doch das ergibt nur einen Haufen Probleme. Da man ja nicht weiß, welche der Eigenschaften es sind, ist es schwierig, die festen von den variablen Eigenschaften zu trennen, vor allem, wenn man über lediglich letztere iterieren möchten. Ja, Iterieren über Objekteigenschaften geht grundsätzlich, ist aber letztlich nur ein Notbehelf. Um die variablen Eigenschaften ansprechen zu können, braucht man variable Variablen, aber dann kann man auch gleich einen Array-Zugriff nehmen. Variable Objekteigenschaften bieten keinen allgemeinen Vorteile gegenüber Arrays.

Ich brauche dazu drei Tabellen:

• Smartphone-Modelle
• Eigenschaften
• Verknüpfung Modelle - Eigenschaften n:n

Das typische EAV-Modell. Aber im vorliegenden Fall ging es wohl nicht um beliebig viele unbekannte Eigenschaften, sondern um Objekte mit bekannten Eigenschaften und nur um einen einzelnen Mechanismus, der diese nicht zu kennen braucht, weil er generisch gestaltet werden soll.

Ist es das, was du suchst?

EAV hat seinen großen Auftritt, wenn es sich zur um erst zur Laufzeit bekannte Eigenschaften handelt. Doch EAV ist kein Allheilmittel. Man wird auch erheblichen nachteiligen Aufwand feststellen, wenn es für bekannte Strukturen verwendet werden soll. Referenzielle Integrität lässt sich zum Beispiel damit nicht vom DBMS sicherstellen. Die Eigenschaftsnamen sind Magic Strings. Hat man den richtigen String, passiert zur Laufzeit das richtige. Aber zur Entwicklungszeit kann man das nicht durch statische Code-Analyse überwachen. EAV hat sich nicht ohne Grund nicht als das allein seelig machende Speichermodell etabliert.

dedlfix.