Gleichstrukturierte Daten richtig getrennt nach Herkunft speichern

verwendetes Datenbanksystem: MS-SQL Server 2008

Hallo zusammen,

sorry für den vielleicht etwas unverständlichen Titel des Posts, aber hier mal eine Erklärung, was ich genau meine:

Ich habe mehrere Schnittstellen, die Daten in identischer Struktur liefern. Die Datenstruktur sieht so aus, es eine "Mastertabelle" M gibt, in der Basisinformationen enthalten sind. Dann gibts noch einige Tabellen, wo z.B. die Quelle Q des Datensatzes und das Ziel Z definiert ist. Diese Tabellen stehen in einer M : Q bzw M : Z = n : 1 Beziehung, d.h. Q und Z sind immer eindeutig und M referenziert auf diese Sätze.
Außerdem gibts dann noch Eigenschaften eines Mastersatzes, wobei nicht jeder Mastersatz die gleichen Eigenschaften hat. Daher gibt es eine Tabelle EN mit den Namen der Eigenschaften und EW mit den Werten der Eigenschaften. Diese Tabellen stehen mit der Mastertabelle über eine zwischengeschaltete Beziehungstabelle in Verbindung.

Jetzt würde ich gerne in der Datenbank unterscheiden, wo die Daten herkommen bzw. die Daten wirklich trennen. I.d.R. würde man ja einfach ein Feld im Masterdatensatz einfügen, und jeder Schnittstelle einen Wert zuweisen. Allerdings kommen über die Schnittstellen sehr viele Daten mit sehr vielen Eigenschaften (Verhältnis Master : Eigenschaft ca. 1 : 60), wodurch die Zuordnungstabelle entsprechend schnell groß wird, was komplexe Abfragen auf die Daten ziemlich verlangsamt. Außerdem muss ich die Daten regelmäßig archivieren, und evtl. unterschiedlich lange aufbewahren.

Wäre es in einem solchen Fall denkbar, mehrere "Tabellensätze" mit identischer Struktur in z.B. unterschiedlichen Schemen (oder gar Datenbanken?) anzulegen, und jede Datenquelle auf einen eigenen Tabellensatz schreiben zu lassen? Oder wenn nicht im gleichen Schema dann die Tabellensätze z.B. einem Prefix im Namen zu unterscheiden?

Gefühlsmäßig ist die Lösung mit Tabellensätzen nicht wirklich schön, aber im Prototypen funktioniert sie soweit sehr gut und ist durch die Trennung der Daten auch schön performant... Gibt's da irgendwelche Designregeln, die mir so was verbieten oder wie würdet ihr so was lösen?

Für Anregungen wäre ich euch sehr dankbar!

Hallo telnet,

klingt nach "Mandantenfähigkeit". Suche mal im Forum danach, das Thema kommt öfters.

Nur kurz: am einfachsten ist es mit verschiedenen Datenbanken. Dann braucht nur der Conn-String angepasst werden.

mfG Gü

Hallo,

das Stichwort ist schon mal sehr gut... danke!
An verschiedene Datenbanken hab ich auch schon gedacht, den Ansatz allerdings wieder verworfen, da ich aus einer GUI Anwendung heraus auf sämtliche Tabellensätze gleichzeitig zugreifen muss...

Wenn ich allerdings jetzt so drüber nachdenke, fallen mir doch einige Dinge ein, die dafür sprechen und keine wirklichen Probleme, die die dagegen sprechen... Danke für den Denkanstoß!

Hallo telnet,

da ich aus einer GUI Anwendung heraus auf sämtliche Tabellensätze gleichzeitig zugreifen muss...

Das beißt sich mit verschiedenen DBs nicht, vorausgesetzt alle sind vom Schema her gleich.

Direkt mit T-SQL gehts exemplarisch z.B. so:

SELECT *
FROM DatabaseA.Schema1.Table1
UNION
SELECT *
FROM DatabaseB.Schema1.Table1

Bei den O/R-Mappern geht das auch, indem die Daten aus den einzelnen DBs in eine z.B. List<T> geladen werden.

Fürs Löschen und Aktualisieren musst du halt die Zuordnung zur Datenbank bewahren. Dazu kannst du eine Klasse mit dieser Metainformation erstellen. Grob so:

public class MetaTable1
{
    public string Database { get; set; }
    public Table1 Table1 { get; set; }
}

D.h. beim Laden der Daten projizierst du mit einem Select die Instanzen von Table1 in eine MetaTable1-Instanz und setzt dabei den Namen der Datenbank, damit dann später im Conn-String die "Data Source" gesetzt werden kann.

Es gibt sicher noch andere Lösungsmöglichkeiten, die passenste für deine Aufgabe musst du dir selbst suchen 😉.

mfG Gü

Hab gerade ggf. was verpasst.
Aber du willst doch eigentlich die Daten per Mandantenfähigkeit trennen benötigst in der GUI aber doch wieder alle.

Wenn die Datenmenge sehr groß ist, bläh das Zwischenspeichern deine Anwendung auf und frisst noch Performance wenn dort Daten ausgewertet werden müssen.
Recht es nicht wenn du nur die Mandanten Daten einlädst und verarbeitest?

T-Virus

Vielleicht hat er ein Webshop: er hat Artikel, auf die jeder Mandant zugreifen darf, aber auch Artikel, die Mandanten-bezogen sind.

Hier würde ich auf eine Trennung der Datenbanken verzichten und stattdessen alles mit wirklich sehr gut durchdachten Relationen und Abhängigkeiten lösen.