Frage

Angenommen, ich habe ein Formular, das drei 10 Felder enthält:Feld1..Feld10.Ich speichere die Formulardaten in einer oder mehreren Datenbanktabellen, wahrscheinlich unter Verwendung von 10 Datenbankspalten.

Angenommen, ich möchte einige Monate später drei weitere Felder hinzufügen.Und in Zukunft kann ich je nach sich ändernden Anforderungen Felder zu diesem Formular hinzufügen/löschen.Wenn ich pro Formularfeld eine Datenbankspalte habe, dann müsste ich bei jedem Formularwechsel die entsprechenden Änderungen an der Datenbank vornehmen.Dies scheint ein Wartungsproblem zu sein.Es muss einen ausgefeilteren Weg geben.

Meine Frage lautet also: Wie entwerfe ich ein Datenmodell, das lose mit meiner Benutzeroberfläche gekoppelt ist?Ein konkreter Anwendungsfall ist ein CRM-System, das durch Benutzer erweiterbar/anpassbar ist.

War es hilfreich?

Lösung

Sofern Sie keinen wirklich guten Grund dafür haben, ist dies im Allgemeinen eine schlechte Idee.Dies macht es sehr schwierig, die Datenbank zu optimieren und zu skalieren.

Wenn Sie es unbedingt tun müssen, dann ist der Vorschlag von Travis für kleine Tische in Ordnung, lässt sich aber nicht wirklich gut skalieren.

Andere Tipps

Sie könnten Felder in eine separate Tabelle abstrahieren, sodass sie viele-zu-viele für die Formulartabelle sind:

Bilden

AUSWEIS
Name
usw.

Feld

AUSWEIS
Etikett
Wert

Formularfeld

FormID
FieldID

Mein Team hat hierfür eine Lösung gefunden, als ich für Quest Computing an AIMS (www.totalaims.com) gearbeitet habe.Zusammenfassend haben wir Wartungsbildschirme hinzugefügt, die es dem Administrator ermöglichten, Metadaten hinzuzufügen und dadurch auch Felder zur Datenbank in bestimmten Tabellen hinzuzufügen.Die Felder wurden auch automatisch zu eigenen Pflege- und Suchmasken hinzugefügt.Wir haben dies auf OpenACS aufgebaut.Mehr erfahren Sie unter www.openacs.org – suchen Sie nach „flexbase“ oder „dynfields“ oder schauen Sie hier www.project-open.org/doc/intranet-dynfield/.Das hat ganz gut funktioniert – der Hauptnachteil war ein Nebeneffekt des Hauptvorteils, d. h.Das Hinzufügen von Feldern könnte von Nicht-DBAs vorgenommen werden, was leicht zu Leistungseinbußen führen könnte.

Ich habe dies in der Vergangenheit mithilfe einer XML-Spalte in der Datenbank getan, um die zusätzlichen Felder zu speichern.Im Allgemeinen habe ich einfach eine große Eigenschaftensammlung in der XML-Spalte und verwende dann XSD, um die Validierung zu erzwingen, wenn ich Aktualisierungen oder Einfügungen durchführe.Wenn ich die Daten abrufe, habe ich Regeln in XSL oder im Objektmodell, die bestimmen, ob das Element angezeigt wird, welche zusätzliche Formatierung angewendet werden soll und für Webformulare, welcher Typ von Eingabeelement basierend auf dem Datentyp im Eigenschaftsknoten verwendet werden soll.

Es funktioniert sehr gut, wenn einige Daten relational und andere Daten erweiterbar gespeichert werden müssen, um den Effekt einer breiten Tabelle mit vielen Nullzeilen zu vermeiden.

Wenn Sie keine relationalen Dinge mit den Daten tun müssen, wie z. B. das Zusammenführen oder Pivotieren mit anderen Tabellen in der Datenbank, dann ist ein einfaches, eigenständiges XML-Formular ebenfalls eine gute Lösung.

Die meisten Datenbanken verfügen mittlerweile über erstklassige XML-Unterstützung für solche Dinge.In SQL Server können Sie beispielsweise ein XSD-Schema direkt in der Datenbank auf eine Spalte eines XML-Datentyps anwenden.In neueren Versionen wird auch die Indizierung dieser Spalten unterstützt.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top