Hallo mal wieder, liebe PHP.de Gemeinde und SQL Gurus. Vielleicht könnt ihr mir weiterhelfen oder zumindest sinnvolle Stichworte liefern, die meine Google-Suche erfolgreicher macht.
Ich möchte Benutzern einer Seite ermöglichen, eigene Prototypobjekte mit entsprechenden Eingabeformularen zu erzeugen. Dafür können Sie für jedes Formularfeld einen Namen, Datentyp und Validierungsregeln, insbesondere ob benötigt oder nicht, festlegen. Aus den Eingaben dieser Formulare werden Objekte erzeugt, deren Attribute durch die Formularfelder gefüttert werden. Diese Objekte möchte ich in einer Datenbank persistieren.
Meine Idee wäre, fünf Tabellen zu nehmen:
1.) "generic_object_definition" (id, name)
2.) "attribute_definition" (generic_object_definition_id, id, type, name)
3.) "validation_rule" (attribute_definition_id,id,rule)
4.) "generic_object" (generic_object_definition_id,id)
5.) "generic_object_attribute"(generic_object_id,attri bute_definition_id,entry)
Zum einen müsste vorm einfügen geprüft werden, ob alle validation rules erfüllt werden.
Zweitens müsste beim Einsetzen von Datenwerten in 5 per Trigger sichergestellt werden, dass attribute_definition_id und generic_object_id an der Selben generic_object_definition_id hängen.
Pro:
Nur valide Attributwerte != null werden gespeichert.
Contra:
- Integritätsprüfung erzwingt Trigger
- Alle Attribute müssten mit Datentyp abgelegt werden, der alles schluckt, z.B. String. Automatische Typprüfung entfällt hierdurch.
Irgendwie sieht dieser Entwurf nicht aus, wie dass, was ich normalerweise für bekannte Objekte mache. Ist mein Gedankengang Blödsinn? Als Alternative fällt mir momentan nur ein, für jedes Objekt ne eigene Tabelle zu erzeugen. Aber ich glaube, niemand will 30.000 Tabellen in seiner Db haben...
Viele Grüße,
Bergtroll
Ich möchte Benutzern einer Seite ermöglichen, eigene Prototypobjekte mit entsprechenden Eingabeformularen zu erzeugen. Dafür können Sie für jedes Formularfeld einen Namen, Datentyp und Validierungsregeln, insbesondere ob benötigt oder nicht, festlegen. Aus den Eingaben dieser Formulare werden Objekte erzeugt, deren Attribute durch die Formularfelder gefüttert werden. Diese Objekte möchte ich in einer Datenbank persistieren.
Meine Idee wäre, fünf Tabellen zu nehmen:
1.) "generic_object_definition" (id, name)
2.) "attribute_definition" (generic_object_definition_id, id, type, name)
3.) "validation_rule" (attribute_definition_id,id,rule)
4.) "generic_object" (generic_object_definition_id,id)
5.) "generic_object_attribute"(generic_object_id,attri bute_definition_id,entry)
Zum einen müsste vorm einfügen geprüft werden, ob alle validation rules erfüllt werden.
Zweitens müsste beim Einsetzen von Datenwerten in 5 per Trigger sichergestellt werden, dass attribute_definition_id und generic_object_id an der Selben generic_object_definition_id hängen.
Pro:
Nur valide Attributwerte != null werden gespeichert.
Contra:
- Integritätsprüfung erzwingt Trigger
- Alle Attribute müssten mit Datentyp abgelegt werden, der alles schluckt, z.B. String. Automatische Typprüfung entfällt hierdurch.
Irgendwie sieht dieser Entwurf nicht aus, wie dass, was ich normalerweise für bekannte Objekte mache. Ist mein Gedankengang Blödsinn? Als Alternative fällt mir momentan nur ein, für jedes Objekt ne eigene Tabelle zu erzeugen. Aber ich glaube, niemand will 30.000 Tabellen in seiner Db haben...
Viele Grüße,
Bergtroll
, ich denke, dass ich das so versuchen werde, falls mir bis Sonntag Abend nix Besseres einfällt. Was mir daran nämlich bisschen Bauchschmerzen bereitet ist, dass ich so Datenbankseitig keinerlei Integritätsprüfung durchführen kann? Diese muss rein Softwareseitig geschehen, oder verstehe ich deine Idee falsch? Hast du so etwas schonmal mit JSON umgesetzt? Hat es gut geklappt ?
Kommentar