Dynamischer Eingriff in das DB-Modell (MySQL < 4)

[DasX]

Ich habe eine Aufgabe bekommen, bei der aus meiner Sicht ein Eingriff in das DB-Modell von PHP aus notwendig wird.

Erläuterung:
Ich entwickle ein Admin-Tool, durch das neue Kategorien angelegt werden können.
Die Kategorien sind, außer der Tatsache, dass es Kategorien sind, nicht auf einen Nenner zu bringen. Durch die Eingabe von Daten in einem Formular (durch den Anwender) sollen diese Kategorien gefüllt werden.
Das klingt erst einmal nach mehreren Tabellen.
Aber ich benötige eine eindeutige Zuordnung (ID => genau 1 Datensatz in einer Kategorie) über alle Kategorien.
Außerdem werden die Anfragen durch den Einsatz von mehreren Tabellen erschwert.

Frage:
Gibt es eine besser Lösung als 1 Schnittstellen-Tabelle (für IDs) und X Kategorie-Tabellen für diese Aufgabe ?

 

[hpvw]

Ich verstehe nicht, was Du meinst.
In wiefern lassen sich die Kategorien nicht auf einen Nenner bringen?
Gibt es gemeinsame Attribute?
Haben die Attribute verschiedene Typen?
Benötigen einzelne Kategorien noch weitere 1:n-Beziehungen?
Ich sehe auch die Kompliziertheit, von der Du sprichst, nicht.

Das einzige, was mir zunächst als grobe Struktur einfällt, wäre eine höchstdynamische, die die Sache aber nicht leichter macht.

Tabelle Kategorie (id, name)

Tabelle IntDatenDefinition (id, bezeichner)
Tabelle FloatDatenDefinition (id, bezeichner)
Tabelle CharDatenDefinition (id, bezeichner)
usw.

Tabelle KategorieBenötigtIntDaten (kategorieID, IntDatenDefinitionID)
Tabelle KategorieBenötigtFloatDaten (kategorieID, FloatDatenDefinitionID)
Tabelle KategorieBenötigtCharDaten (kategorieID, CharDatenDefinitionID)
usw.

Tabelle KategorieIntDatenValue (kategorieID, IntDatenDefinitionID, Wert)
Tabelle KategorieFloatDatenValue (kategorieID, FloatDatenDefinitionID, Wert)
Tabelle KategorieCharDatenValue (kategorieID, CharDatenDefinitionID, Wert)
usw.

Wenn man an der Struktur noch ein bisschen bohrt, lassen sich bestimmt auch Arrays von Chars (etc.), also eine 1:n-Beziehung zwischen einer Kategorie und einem bestimmten Attributbezeichner, wie z.B. mögliche Farben eines Produkts in einem Shop, abbilden.

Wenn Du das ausreichend durchdenkst mußt Du vermutlich nie wieder an die Struktur, sondern kannst alles durch Tabelleneinträge lösen.
Wenn Du den Spaß auf die Spitze treiben willst, ermöglichst Du Unterkategorien und implementierst noch eine Vererbungsstruktur über Verknüpfungstabellen, damit Attribute einer Oberkategorie automatisch in Unterkategorien benötigt werden oder (entgegen der Objektorientierung) auch in Unterkategorien wieder ausgesclossen werden können.

Allerdings macht so eine Struktur die Abfragen nicht leichter. Die Übersicht in der Datenbank geht dann natürlich auch weitestgehend verloren.

Ich bin jetzt bewusst mal ein bisschen ins "spinnen" geraten, damit Du in erster Linie siehst, dass es immer komplizierter geht.

Ohne jetzt Dein Problem exakt verstanden zu haben (und auch ohne die Inhalte zu kennen), sehe ich wenig Probleme, für jede Kategorie eine Tabelle zu machen und auf die ID-Verknüpfungstabelle zu verzichten.
Handelt es sich z.B. um ein CMS, in dem Du einen Blog, eine Linkliste und statische Seiten unterbringen willst, halte ich es für sinnvoll, eine eigene Tabelle für jeden Bereich anzulegen, die unabhängig von den anderen Tabellen ist.
Handelt es sich aber um einen Shop, so würde ich auf zu detaillierte Attribute verzichten und nur gängiges, wie z.B. Bezeichnung, Beschreibung, Preis etc. in einer Tabelle unterbringen (oder halt den oben angedeuteten Irrsinn durchziehen).

Gruß hpvw