MSSQL dyn. Tabellen vs. XML Column
verwendetes Datenbanksystem: MSSQL
Hallo zusammen,
wir führen aktuell eine Diskussion zum Thema wie man Daten am besten abspeichern sollte / könnte um Sie dann möglichst performant abrufen / anzeigen zu können.
Aktuelle Situation:
In einer DB Tabelle werden Kopfdaten gespeichert, wobei es zusätzlich eine Spalte mit XML-Daten gibt, die dynamische Daten beinhalten (das Quellsystem schickt eine pro Datensatz variierende Anzahl an Attribut- / Wertepaaren mit).
Eig. wäre das ein Fall für eine NoSql SB gewesen, hatten wir aber leicht nicht zur Verfügung.
Wir laden die Daten in eine Clientanwendung und lösen da das XML dann auf, generieren also dynamisch Objekte die dann alle vorkommenden Spalten beinhalten.
Gegenvorschlag aktuell:
Wir erstellen zur Kopfdatentabelle eine Erweiterungstabelle mit gleichem Schlüssel und einer 1:1 Beziehung. Die Erweiterungstabelle soll dynamisch erweitert werden / sich selbst aufbauen, d.h. wenn ein noch unbekanntes Attribut daherkommt soll einfach eine Spalte angefügt werden.
Grund für die aktuelle Diskussion ist die Performance der GUI Anwendung, die die Daten anzeigt. Meiner Meinung nach würde ich lieber Aufwand in die Optimierung des Ladens der Daten stecken als die DB so wie beschrieben umzubauen... Sicher geht dann das Abrufen der Daten wahrscheinlich schneller aber es widerstrebt mir einfach eine Tabelle dynamisch sich selbst verändern zu lassen aufgrund der Daten, die reinkommen.
Was denkt ihr da? Gibt's da sachliche / fachliche Argumente für so was oder ist das "Ansichtssache"?
VG
Überleg dir wie performant das sein wird wenn 10, 100, .... neue Attribute hinzukommen, ihr dann eine Tabelle habt die hauptsächlich leer sein wird und ihr ja auch zig leere Spalten zu einer Zeile zurückbekommt.
Wenn schon dann packt doch lieber pro Attribut eine Zeile in eine Tabelle. Da steht dann drin wozu das Attribut gehört, wie es heißt und sein Wert.
Noch sinnvoller halte ich deinen Vorschlag mit der Performance Optimierung. Ich tippe mal ins blaue und vermute, wenn die Anwendung mit den "bisschen Daten" die in die Anzeige passen ei Problem hat, gibt es wirklich noch was zu optimieren.
Hi,
Zur aktuellen XML-Variante:
Ist zwar aus Anwendungssicht ne nette Sache, die man unter Garantie auch performant genug gestalten kann - wirklich mögen würde ich das aber ehrlich gesagt nicht, weil Reports auf SQL-Basis damit super aufwändig bis unmöglich werden. (falls man das gerne hätte)
Bei der Spalten-Variante:
Fände ich nicht lustig, wenn sich immer wieder mein DB-Schema ändert - auch möchte ich chilic hier beipflichten - aus Sicht der Performance tut man sich damit sicher auch keinen Gefallen.
Bei einer Extra-Tabelle:
Prinzipiell kenne ich das auch so, wie chilic es beschreibt - man legt je nach Basistyp eine (oder auch mehrere) Attribut-Tabelle an, welche beinhaltet, welche Extra-Attribute (und eventuelle Datentypen, Regeln,...) es neben den Kopfdaten noch gibt. Dann eine weitere Zusatztabelle, welche dann den PK des Objekts, den PK des Attributes und den entsprechenden Wert eines Objekts beinhaltet.
Persönlich in der Situation würde ich allerdings bei XML bleiben, da ich nicht glaube, dass ihr von der DB-Seite aus Performance-Probleme habt - sondern ohnehin den Client optimieren müsst. (egal bei welcher Lösung)
LG