Vorbereitung für den Wechsel zu einer einzigen Datenbank

Question

Wir haben eine Anwendung, die 1000+ Datenbanken und 600+ Sprocs hat. Jede Datenbank repräsentiert einen anderen Client.

Problem: Wir müssen dies zu einer einzigen Datenbank verschieben, während so wenig Wirkung auf die ui wie möglich zu erstellen, das heißt, ändern Sie nicht alle Sproc-Signaturen auf einmal.

Die Verbindungszeichenfolge legt derzeit das Datenbankattribut fest, ein Vorschlag besteht darin, das Benutzerattribut zu verschieben. Dieses Attribut (mit SYSTEM_USER) könnte verwendet werden, um die Site-ID zu bestimmen, die für die WHERE-Klausel verwendet werden würde.

Das obige wäre keine endgültige Lösung, sondern erlaubt es uns, Änderungen an der Sproc-Signatur in einem langsam kontrollierten Tempo vorzunehmen. Sobald alle fertig sind, können wir den Connstring korrigieren und ein Verbindungspooling erhalten.

Gibt es eine Beschränkung der Anzahl der Logins/Benutzer, die wir auf sqlserver 2005/8 haben können? Oder ist jemand diesen Weg gegangen, der eine bessere Option beleuchten könnte?

Answer 1

Siehe meine Antwort hier Ideas for Combining Thousand Databases into One Database

Klingt wie Sie zwei das gleiche Projekt arbeiten. Sie müssen jedes Proc ändern, bevor Sie zu einer Datenbank wechseln können, oder jeder Client wird die Daten der anderen sehen.

Answer 2

Wie für die Anzahl der Logins auf SQL Server 2005/08 - ich glaube nicht, dass jemals jemand hier auf eine harte Grenze gestoßen ist. Ein paar tausend werden NICHT irgendein Problem überhaupt sein.

Was Sie für dieses Szenario berücksichtigen könnten, könnte ein Schema in Ihrer einzelnen Datenbank pro Kunde sein, z. Kunde "Miller" hat ein "Miller" -Schema mit seinen Objekten im Inneren, und Kunde "Brown" hat ein "braunes" Schema.

Und im Gegensatz zu dem, was HLGEM gerade geantwortet hat - nein, Kunden werden nicht sehen, ihre anderen Daten, wenn Sie die entsprechenden Berechtigungen angeben - jeder Kunde (und seine Benutzer) in nur sein eigenes Schema - sollte gut funktionieren.

Marc

Answer 3

Sie auch eine besondere Anwendungsname Einstellung in der Verbindungszeichenfolge prüfen könnte, anstatt einen unverwechselbaren Benutzer verwenden, die Sie in where-Klausel mit APP_NAME bekommen kann(). Ich bin sicher, dass SQL Server kein Problem mit Tausenden von Logins haben wird, aber Sie möchten möglicherweise nicht sie erstellen müssen.