cycap

Also ist dein Ansatz ähnlich wie Ansatz 2, nur mit zusätzlich einer Tabelle die die zusätlich verfügbaren Felder und die dazugehörigen Bedingungen enthält?

Bei meiner Überlegung ging der Schritt nur an andererr Stelle noch weiter um nicht alle Inhalte in TEXT-Datentypen speichern zu müssen. Was denkst du darüber?

Mister Ad

dr.e.

Ähnlich ja, nur der Context wurde dort - soweit ich das noch im Kopf habe - nicht berücksichtigt.

Falls du das nicht möchtest, kannst du ja pro Attribut-Type eine eigene Objekte vorsehen (z.B. IntegerAttribute, TextAttribute, ...) und entsprechend in der DB abbilden sowie die zugehörigen Beziehungen um die neuen Typen erweitern (z.B. Order <>--- IntegerAttribute ---<> Context). Das wird dann allerdings etwas komplizierter in der Abfrage weswegen ich bei einem Attribut-Objekt-Typen bleiben würde.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

cycap

Das ich das KANN ist mir klar, ich wollte nur wissen was deine Meinung dazu ist.

mquadrat

Für dieses Problem habe ich auch noch keine "allumfassende" Lösung gefunden. Abhängig ist es ja auch noch davon, was später mit diesen "Custom-Attributen" gemacht werden soll. Solange das nur beschreibende Daten sind ist ein Aufsplitten in mehrere Tabellen ja kein Problem. Wenn diese aber fest in Funktionen verwendet werden, kann es u. U. doch wieder günstiger sein sie mit in die Basistabelle zu nehmen, als immer zu prüfen ob es dieses oder jenes Attribut im aktuellen Kontext gibt. Dazu gibt es noch mehr einschränkende Faktoren wie z.B. das verwendete Framework oder die Abfragetiefe (je nach DB Aufbau kommt man mit mehreren Attribut-Tabellen vielleicht an das Join-Limit der Engine ran).

Worauf ich hinaus will: Theoretische Konzepte sind schön und gut, aber oft werden die zur Verfügung stehenden Möglichkeiten duch Rahmenbedingungen begrenzt.

__________________
Wir suchen PHP / Delphi und .NET Entwickler im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

strolch75

vielleicht wäre es eine Option einfach für jeden Kunden eine Tabelle anzulegen? - bist unabhängig für die Spezialwünsche deiner Kunden - und der Admin kann mit Joins auch problemlos alles Anzeigen lassen.

mquadrat

Die Idee ist gar nicht mal sooo schlecht. Man könnte mit Vererbung arbeiten, dann würde es auf den OR-Mapper (falls verwendet) ankommen wie das resultierende DB-Modell aussehen muss. Naben abweichenden Daten könnte man auch noch abweichendes Verhalten implementieren. Hat aber den gravierenden Nachteil, dass man u.U. redundanten Code bekommt. Wäre unschön.

__________________
Wir suchen PHP / Delphi und .NET Entwickler im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

cycap

Was aber zur Folge hätte das ich bei jedem neuen Kunden und sogar bei jedem neuen Feld die Datenbankstruktur ändern müsste und meinem Code bzw. meinem OR-Mapper die Änderungen mitteilen müsste und das ist nicht sinn der Sache.

dr.e.

-->
+
Ich würde alle Attribute auslagern und einfach in einer Konfiguration (hierfür kann es ja auch eine GUI geben) die bekannten Attribute definieren.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

cycap

Das würde doch aber bedeuten ich müsste auf DB Funktionen die Typ-Spezifisch sind verzichten oder explizit casten oder? Und die Fragmentierung bzw. der Speicherverbrauch würde auch enorm ansteigen oder? Hast du soetwas schonmal umgesetzt?

dr.e.

Hallo cycap,

sofern du die Attribute als "nur Text" speicherst musst du die Typensicherheit in deiner Applikation behandeln (Form-Filter, bzw. -Validatoren).

Fragmentierung ist nur bei sehr häufigem Ändern von Attribut-Definitionen ein Problem und der Speicherverbrauch ist nur dann höher, wenn die Datenbank die volle Text-Länge pr Zeile reserviert. VARCHAR z.B. ist hier intelligent genug, nur den relevanten Speicher zu allokieren.

--> Objektorientierte Implementierung eines Gstebuchs :: Adventure PHP Framework (APF) (ist auch im PHP-Journal erschienen)

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~