MSSQL und Schemata

[ukulele]

Moin.

Ich hab grade mal kurz dern Artikel zur Migragtion auf PostgreSQL überflogen, grundsätzlich interessant.

Datenbank-Migration beginnt im Kopf

Schöner Blog-Beitrag "Migrate your mindset too" der dazu auffordert, bei einer Migration zB nach Postgres nicht alles 1:1 umzusetzen sondern umzudenken: Migrate your mindset too - Thoughts about SQL Danke an @castorp für den Link.

www.datenbankforum.com

Jetzt werde ich mir wohl erstmalig einen MSSQL Server mit "freier" Lizenz holen sobald die neue Version verfügbar ist. Bisher ist meine Landschaft SQL Express, SQL Standard aber mit einer eingeschränkten Lizenz die nur für ein Produkt gilt und einer Developer Instanz. Der neue DB Server wird dann erstmalig wirkich mehreren Anwendungen dienen und mehrere jetzige Datenbanken auf einem System vereinen.

Da frage ich mich natürlich, was ist gänige Praxis und realisitisch umsetzbar? Die Datenbanken sind ja teilweise durch die Software bestimmt, da kann oder sollte ich vermutlich nicht einfach das Schema ändern denke ich. Aber ich wüsste auch nicht wirklich warum man nicht mehrere DBs auf einem DBMS betreiben sollte, wenn es sich um weitestgehend getrennte Applikationen handelt. Was haltet ihr für sinnvoll?

 

[Chuky666]

Moin moin

so wie ich das kenne greifen die Apps auf eine oder mehrere DB´s zu die entsprechend benannt sind. Demzufolge ist es kein Problem mehrere DB´s auf einem Server zu haben. Das haben wir auch. Es gibt natürlich auch Softwarehersteller die verlangen einen eigenen DB-Server.

 

[ukulele]

Das würde ich auch als gängige Praxis sehen und das ist natürlich auch kein Problem.

Jetzt, bezogen auf den Artikel, frage ich mich halt ob man mehr mit Schemata statt getrennten DB Instanzen arbeiten sollte und wenn ja warum. Als Nachteil würde ich vermuten das die Datenbanken dann natürlich größer werden und nur schlecht trennbar sind, z.B. für gezielte Backups. Andererseits könnte es ja vielleicht Performance bringen wenn statt von einer auf die andere Datenbank nur Schema-übergreifend zugegriffen wird.

Überhaupt arbeite ich gar nicht gezielt mit Schemata bisher. Was gewinne ich damit außer einer logischen Trennung?

 

[akretschmer]

Ich kenne Kunden, die haben eine Web-basierte Anwendung mit vielen Tenants, also eigenen Kunden. Die App benötigt einen gewissen Satz an Tabellen, die aber für jeden einzelnen Kunden gleich sind. Die haben das über je Kunde 1 Schema innerhalb einer PostgreSQL-DB gelöst.

Hat Vor- und Nachteile:

• weniger Aufwand, statt vieler kleiner DBs nun eine große mit vielen Schemas
• da einige 10.000 Kunden dementsprechend einige 10.000 Schemas mit je einigen hundert Tabellen -> sehr große pg_class - Tabelle und andere Kataloge
• Möglichkeit, über alle Kunden Abfragen zu stellen (via schemaname.tablename kein Problem, cross-Zugriffe über Datenbanken hinweg sind mit PG möglich, aber aufwendiger)

Das mal so in knapp. Hab derzeit einen Kunden, der auch zwischen sehr vielen kleinen Datenbanken als Microservice versus eine zentrale DB schwankt. Ich halte letzteres für besser wartbar, allerdings dann ein single point of failure ... also muß entsprechend HA her, via BDR. ...

 

[Chuky666]

Ich persönlich wäre eher für getrennte Instanzen oder Server wenn die Applikation keine Mandanten Trennung kann und nur die selben Tabellen benutzt, anstatt Schemas einzuführen. Schema finde ich zB. bei der Trennung von Auftrags Tabellen zu Stammdaten usw. sinnvoll.

 

[ukulele]

Also organisatorisch klingt das sinnvoll in einigen Situationen auf Schemata statt getrennten DBs zu setzen. Technisch scheint das aber nicht so wirklich groß anders zu sein, abgesehn davon das es eventuell schwerer ist bei PG Querys über mehrere DBs zu fahren (bei MS geht das relativ einfach).

@akretschmer
Bei deinem beschriebenen Fall muss dann aber auch pro Tabelle und Schema ein Join oder Union gemacht werden, oder kann man vielleicht auch irgendwie eine Tabelle nehmen und "partitionieren" nach Schema um dann einfach das Schema als Auswahlriterium für Datensätze zu verwenden?

 

[akretschmer]

ich versteh Deine Frage nicht ganz. Wenn ein Kunde sich mit der DB verbindet, wird der search_path auf sein Schema gesetzt, damit sieht er nur die für ihn relevanten Tabellen. Außerdem darf er auch nur auf 'sein' Schema zugreifen.

Ach, jetzt versteh ich die Frage: naja, es ist eigentlich nicht notwendig, eine Abfrage über alle Schemas zu machen - aber machbar. Müßte man sich dann dynamisch zusammenbasteln...

 

[ukulele]

Okay dann ist das Schema wirklich nur eine "organisatorische" Trennung, verhält sich aber eben wie eine eigene DB bzw. eine eigene Tabelle. Mir geht es darum zu verstehen worin die Unterscheide liegen bevor ich anfange fleißig DBs bzw. Schemata anzulegen.

 

[akretschmer]

jein, schemas sind eigene Namenräume. Du kannst nicht im Schema Public 2 Tabellen 'test' haben, aber Du kannst 2 Schemas schema1 und schema2 haben, und in diesen jeweils eine Tabelle 'test'. Je nachdem, wie search_path gesetzt ist, wird bei 'select * from test' nun zuerst die in schema1 oder schema2 gefunden - oder gar keine, wenn weder schema1 noch schema2 im search_path sind.

 

[dabadepdu]

schemas sind eigene Namenräume...

Und Du kannst unabhängig vom Namensraum auch Benutzer spezifische Rechte vergeben.
Also im Zweifel mit dem Ergebnis:
Select * from test;
Ist zwar erlaubt, funktioniert aber nicht.
Select * from schema1.test;
Erlaubt und funktioniert usw.

Das geht nicht mit verschiedenen DB Instanzen.
Und im Sinne von Micro Services:
Heute würde man vielleicht am ehesten bei der Programmierung darauf Wert legen, frei wählbare Schnittstellen (aka DB, Instance, Schema, View, Datenquelle..) von Anfang an zu präferieren. Am Ende steht beim Entwickler (alles auf einem System, einer DB - sofern sie es kann) immer die gleiche DB, nur verschiedene Schemata. In Production kann das customisiert werden und von "irgendwo" kommen. (Was allerdings dann auch separater Berechtigung in den Einzelsystemen bedarf und zentrale Nutzung durch einen User verhindert. Kann unpraktisch sein oder gewollt)

 

[Dukel]

Man darf die Begriffe nicht durcheinander bringen, da bei verschiedenen DB die selben Begriffe unterschiedliche genutzt werden.
Unter MSSQL gilt folgendes:
Auf einem Server kann man mehrere SQL Server Instanzen installieren. (wobei man dies vermeiden sollte!)
In jeder Instanz können mehrere Datenbanken installiert werden.
In jeder DB können unterschiedliche Schemas erstellt werden.
Innerhalb eines Schemas (per Default dbo) kommen die Inhalte (Tabelle, Views,...).

Wir haben bei Kunden sowohl viele Datenbanken auf einem Server oder auch getrennte Server (je nach Applikation und Anforderung) mit je Datenbank(en) für eine Applikation.

 

[ukulele]

Man darf die Begriffe nicht durcheinander bringen, da bei verschiedenen DB die selben Begriffe unterschiedliche genutzt werden.
Unter MSSQL gilt folgendes:
Auf einem Server kann man mehrere SQL Server Instanzen installieren. (wobei man dies vermeiden sollte!)
In jeder Instanz können mehrere Datenbanken installiert werden.
In jeder DB können unterschiedliche Schemas erstellt werden.
Innerhalb eines Schemas (per Default dbo) kommen die Inhalte (Tabelle, Views,...).

Ich hätte mal angenommen das es bei PostgreSQL auch so ist oder nicht? Also zumindest was das Schema angeht.

 

[akretschmer]

ja, sehr ähnlich auf den ersten Blick

 

[dabadepdu]

Man darf die Begriffe nicht durcheinander bringen, da bei verschiedenen DB die selben Begriffe unterschiedliche genutzt werden.

Ja, technisch ist das so, aber in meinem Sinne egal. Ich wollte darauf hinaus, dass es nicht nur eine Frage der Fähigkeiten der DB ist, ob sie Schemata anbietet.
Letztlich "entscheidet" die Anwendung über den Zugriff. Wenn sie nur mit einer Connection oder einem Pool arbeitet, dann habe ich keine Granularität und keine Mikroservices. Diese Problematik müsste ich mit modellieren und durch die Nutzung einzeln zuständiger Connections umsetzten (die halt durchaus alle identisch sein können).

Ein Server, eine Instanz, ... hat m.E. auch Auswirkungen auf den Bedarf an RAM (Shared Memory > identische Daten stehen einmalig für alle zur Verfügung und werden auch nur 1x gepflegt) und den administrativen Aufwand. Mit 10000 Nutzer Schemata habe ich nur 1x den Aufwand eines Upgrades oder Patches, statt 10000 DB Installationen. Das gilt für DB Binaries, aber am Ende auch für das Datenmodell. Mit Multi Tenancy wie bei Oracle bspw. habe ich am Ende auch weniger Aufwand bei Wartung und Support von 10000 Mandanten Schemata.

 

[ukulele]

Bei mehreren Instanzen habe ich vermutliche auch mehrere Temp-DBs und bei mehreren Schemata nicht oder?