nikosch

Eben nicht. Daten ja, Struktur nein.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mister Ad

phpsecretary

Ich kann mich nur auf das beziehen, wonach du fragst.
Wenn Dein Beispiel zu weit hergeholt ist, wozu dann das Beispiel?

In jedem Fall ist ein Ansatz mit "ORDER_VAL_INT, ORDER_VAL_CHAR,..." etwas für eine Tonne.

God object – Wikipedia

__________________
Ich bin Programmierer und kein Frameworkinstallierer.

phpsecretary

Ganz sicher sogar...

__________________
Ich bin Programmierer und kein Frameworkinstallierer.

cycap

Es hat schon einen Grund warum ich diesen Thread in einen Bereich des Forums gepackt habe der die Beschriftung

hat. Es geht ums Konzept und das Beispiel war nur dazu gedacht um verständlich zu machen worum es geht.

Ob es nun 20 oder 20.000 Kunden sind spielt doch beim Konzept keine Rolle. Und ebenso ist es für das Konzept unwichtig ob es um Bestellungen oder zum Beispiel um Foren-Beiträge geht.

Mal abgesehen davon wiedersprichtst du dir mit dem Link zum God-Object selbst, denn meinem ORM-Objekt "Bestellung" von Kunde A braucht nicht zu interessieren das es bei Kunde C noch eine Beziehung zu einer Lieferadresse gibt. Rein theoretisch natürlich.

cycap

Können wir das Thema noch weiter diskutieren? Gibt es vielleicht noch weitere Ansätze oder hat noch jemand anderes eine Meinung dazu?

dr.e.

Warum abstahierst du nicht die Attribute eines Objekts? Dann kannst du je nach Konfiguration ein Objekt "Bestellung" komponieren.

__________________
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

Du meinst Ansatz 1 ?

dr.e.

Hi cy,

nein so nicht. Ich denke da an eine Beziehung zwischen einem Objekt "Order", einem "Attribut"-Objekt und einem "Context" oder "Customer". Also soetwas:

Damit kannst du dir - sofern der "Context" in deinem Datenmodell noch mit dem Kunden in Beziehung steht - ein absolut generisches Daten-Modell bereitstellen. Man könnte dann noch je nach "Context" noch in eigene Domänen-Objekte mappen um eine klare API zu haben - quasi als Customization.

__________________
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

Hallo dr,

ich bin mir nicht sicher ob ich dich richtig verstehe.

Ich verstehe das so: Das Objekt Order enthält alle funktionalitäten/Werte die für jede Order gelten und das Attribut Objekt alle zusätzlich möglichen Werte. Das Context-Object beschreibt dann unter welchen Bedingungen welche Attribute genutzt werden, verstehe ich das soweit richtig?

Falls ja, wie würde das in einer relationalen Datenbank aussehen? Ich kann mir das nicht so richtig vorstellen.

Gruß
cy

dr.e.

Hallo cy,

ds kannst du in beide Richtungen interpretieren. Entweder hält das Basis-Objekt (hier Order) keine Attribute oder nur den Basis-Satz. je nach Anwendungfall ist die eine oder die andere Vorgehensweise sinnvoll.

Das ist eigentlich ganz einfach durch Teil-Normalisierung abbildbar. Du erzeugst eine Tabelle für jeden Objekttypen und zwei Tabellen für die Abbildung der Beziehungen. Durch 4 JOINs kannst du dann die Attribute zu einem Objekt in einem Kontext laden.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~