xm22

Hi,

ich versuche es mal hier, da ich denke, es ist nicht ausschließlich auf das DB-Design beschänkt. Folgendes:
Ich habe einen Entity-Typ "Eintrag". Dieser hat mehrere Werte wie z. B. der Benutzer, der ihn erstellt hat, Zeitpunkt der Erstellung, etc.

Jeder Eintrag hat jedoch einen speziellen Typ, der mehrere zusätzliche Informationen bringt. Ich nehme mal als Bsp. eine Gebrauchtwaren-Börse:

Man kann einen Eintrag erstellen und weist diesem einen bestimmten Typ zu (z. B. Auto, Möbel, Kleidung, wie auch immer). Jeder dieser Typen, verfügt über eigene Merkmale.

Man könnte jetzt sagen, dass man Autos, Möbel, usw. in entsprechende Kategorien packt und dann innerhalb der Kategorie "Auto" nur Autos ausgibt.

Jedoch soll jetzt die Navigation regional orientiert sein. Das heißt, man soll z. B. alle Möbel, Autos, usw. für Berlin darstellen.

Das habe ich im Moment so gelöst, dass es eine Tabelle t_entries gibt und zusätzlich für jeden Typ eine weitere Tabelle, die die Informationen typspezifisch erweitert (z. B.: Leistung bei Autos).

Allerdings ist das in meinen Augen nicht besonders toll - daher die Frage, ob jemand weiß, wie man das besser machen kann...


EDIT: Ich habe es in diesem Bereich gepostet, da letztendlich auch die Implementierung innerhalb der Applikation damit funktionieren muss.

Mister Ad

Baltasar

dann macht ein db-design einfach keinen sinn....

eine relation für autos, eine für besitzer, eine für die beziehung...dritte normalform....

mit dem entity-typ "eintrag" wirst du es nicht weit bringen

dr.e.

Hallo xm22,

ich denke, du solltest nicht von einem DB-Design (ER-Modell) ausgehen, sondern vom Domänen-Modell. Für mich hast du mehrere Objekte:

• Entry
• EntryAttributes
• Category
• City

Die ersten beiden stellen die Informationen eines Eintrags dar, wobei EntryAttributes ein generisches Attribut-Objekt ist, die du mehrfach unter Entry komponieren kannst. Damit ist das Thema gelöst, dass du beliebige Attribute an ein Auto oder ein Möbelstück hängen kannst, ohne Vererbung auf DB-Ebene nutzen zu müssen.

Die beiden letzten sind mehr oder weniger beide Ordnungs-Kriterien, die die jeweils relevanten Entry-Objekte assoziieren. So kannst du ohne Probleme abfragen, welche Autos in welcher Kategorie oder in welcher Stadt zu haben sind.

Wichtig bei allen Modellen: du musst zuerst überlegen, welche Objekte du hast und wie diese in Verbindung zueinander stehen. Dann wirst du dir viel leichter tun, das später in eine DB abzubilden. Mit dem GenericORMapper ist das übrigens straight forward, denn das UML kannst du quasi 1:1 in die Konfiguration übernehmen.

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

xm22

Soweit alles klar, aber wie würdest Du das in einer DB abbilden? Eine Tabelle für Entries und eine für Attribute? D würde dann allerdings die Typisierung fehlen..

dr.e.

Hi,

ich würde für alle Objekte eine eigene Tabelle erstellen und die Beziehungen über jeweils eine weitere Tabelle. Sofern du nur 1:n oder n:1 benötigst, kannst du in der gegenüberliegenden Tabelle auch nur den Fremdschlüssel speichern.

Exakt.

Nein, diese wird über die Beziehungen und deren Bedeutung klar.

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

xm22

Nicht, dass das ein Missverständnis ist: Ich meinte _eine_ Tabelle für alle "zusätzlichen" Attribute aller Entry-Typen, quasi:
Entry-Tabelle:
id|type|standardinfo1|standardinfo2|...

Attributstabelle
f_entry_id|key|value


Oder meinst Du, für jeden Entry-Typ eine eigene Attributstabelle?

dr.e.

Denke doch nicht immer ausgehend von Tabellen, sondern von Domänen-Objekten. Wir hatten doch oben diskutiert, dass ein Entry-Objekt mehrere Attribute-Objekte komponiert. Das bedeutet im ER-Diagramm, dass du eine Tabelle entries hast und eine attributes. Dazwischen existiert ein Beziehungstabelle oder du speichert per FK in der attributes-Tabelle die Zuordnung.

Eben.

Nein.

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

nikosch

Vgl. Diskussion hier: http://www.php.de/datenbanken/64428-...tml#post491997

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

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

xm22

@Dr.E.: Aber wie soll man das auslesen? Angenommen, man möchte 20 dieser Einträge - Dann muss man ja auch 20x die Attributstabelle auslesen.

EDIT: Gerade habe ich den von Nikosch verlinkten Beitrag gelesen.. Ich habe mal dort weiter geschrieben, weil es da schon mehr Facetten als hier gibt. Vielleicht sollte man den Beitrag hier dort mit anknüppern oder mit Verweis auf den anderen schließen.