Du setzt Datenbank und Schemata gleich
Ich setze es nicht gleich, das wäre tatsächlich falsch, ich gebe eine gängige Sichtweise wieder und möchte auf etwas anderes hinaus. Nebenbei, Schemata in DB sind keine Erfindung von MS und weit mehr als ein Sicherheitsfeature.
Ich sprach u.a. im Kontext von Micro Services.
10 T Logins sehe ich auch nicht als so ungewöhnlich an, wäre auch die Frage, was mit „Login“ genau gemeint ist. Und was auch immer, ein „Login“ wird nicht mit Spitzhacke und Schaufel angelegt. Genauso wenig sind 10 T Kunden oder ein Vielfaches ein Problem, alles nur DV, also klassisches DB Server Terrain, teilweise auch OS.
Ich versuche es noch einmal, habe mich offenbar wieder missverständlich ausgedrückt.
Die Diskussion scheint mir einfach etwas schräg. In der Realität arbeiten viele Entwickler (oder auch Architekten) traditionell mit recht monolithischen Konzepten. Eine DB, ein Schema, alles rein, fertig, Anwendung läuft. Nur ist sie halt auf diese Art recht unflexibel. Denn an dieser Stelle spielt es in der Praxis eben oft keine Rolle, dass Schema, Instanz, .. besondere Funktionsmerkmale sind, die man nutzen könnte. Ich kann mit einem 32t LKW Briefe ausliefern und sogar Gründe finden, warum das in bestimmten Situationen dann doch effizient und sinnvoll ist.
Wenn ich mir also auf der einen Seite Gedanken mache, was man alles Tolles mit DB, Schema, Instanz, .. machen kann (sofern das System es bietet), hilft mir das alles wenig, wenn ich auf der anderen Seite meine Applikationen nicht entsprechend konzipiere. Zur praktischen Veranschaulichung: Eine(1) Anwendung, die mit einer(1) einzigen Connection arbeitet (ich rede nicht von Pooling), zeigt schon dieses Denkmuster. Bei kommerziellen Anbietern ist es ja bspw. so, dass bestimmte Konstellationen der Produktnutzung gar keine logischen/fachlichen Gründe haben, sondern lediglich mit der Nutzung der verfügbaren/erlaubten/gekauften Lizenzierung einen „Sinn“ ergeben (juristisch bzw. wirtschaftlich).
M.E. ist das tw. ein historisches bedingtes Problem, einerseits durch die früher verfügbare Hardware, andererseits durch Lizenzbestimmungen kommerzieller Anbieter. Hat man sich also die a..teure Hardware mal hingestellt (soll ja ein paar Jahr(zehnt)e reichen) und die a..teure Softwarelizenz (Vollversion) gekauft, kommt schnell der Punkt, wo man aus Wirtschaftlichkeitsgründen oder anderen Sachzwängen (Datenschutz, (Ausfall-)Sicherheit, ..) nach weiteren Nutzungsmöglichkeiten sucht. Dann nehmen wir eine neue Instanz, ein anderes Schema, eine neue Softwareversion etc. pp her und freuen uns, was alles geht.
Heute hat sich aus ähnlichen Gründen die Virtualisierung recht weit entwickelt und man könnte viele alte Zöpfe abschneiden. Sprich ein MS SQL Server oder Postgres könnte in der Hinsicht DB, Schema, Instanz weniger können, man würde die Funktionen mittlerweile anders realisieren.
Wie gesagt, was die (DB) Serverwelt da bietet, ist die eine Seite, was ich über die Anwendungsarchitektur des Client daraus mache, ist eine andere Sache. Beides getrennt zu betrachten, macht relativ wenig Sinn.
In großen Systemen sieht das Ganze sicher noch etwas anders aus, aber das ist auf der Ebene, die hier in den Foren meist diskutiert wird, sicher nicht das Hauptthema.
