Préparation du transfert vers une base de données unique

Question

Nous avons une application qui contient plus de 1000 bases de données et plus de 600 sprocs. Chaque base de données représente un client différent. Problème: Nous devons déplacer ceci vers une base de données unique tout en créant le moins d'effet possible sur l'interface utilisateur, ce qui signifie ne pas modifier toutes les signatures de sproc à un moment donné.

La chaîne de connexion définit actuellement l'attribut de base de données, une proposition consiste à le déplacer vers l'attribut utilisateur. Cet attribut (using SYSTEM_USER) pourrait être utilisé pour déterminer l'identificateur de site qui serait utilisé sur la clause where.

Ce qui précède ne serait pas la solution finale, mais nous permet d'apporter des modifications à la signature sproc à un rythme contrôlé lent. Une fois que tout est fait, nous pouvons corriger le lien et obtenir un certain nombre de connexions.

Y a-t-il une limite au nombre de connexions/utilisateurs que nous pouvons avoir sur sqlserver 2005/8. Ou est-ce que quelqu'un a été dans cette voie qui pourrait faire la lumière sur une meilleure option.

Answer 1

Voir ma réponse ici Ideas for Combining Thousand Databases into One Database

On dirait que vous travaillez deux le même projet. Vous devrez changer chaque proc avant de pouvoir passer à une base de données ou chaque client verra les données des autres.

Answer 2

En ce qui concerne le nombre de connexions sur SQL Server 2005/08, je ne pense pas que quiconque ait jamais rencontré une limite stricte. Quelques milliers de pas être aucun problème du tout. Ce que vous pourriez envisager pour ce scénario pourrait être un schéma à l'intérieur de votre DB unique par client, par ex. le client "Miller" a un schéma "miller", avec ses objets à l'intérieur, et le client "Brown" aura un schéma "marron". Et contrairement à ce que HLGEM vient de répondre - non, les clients ne verront pas les données des autres, si vous spécifiez les autorisations appropriées - chaque client (et ses utilisateurs) dans son propre schéma seulement - devrait fonctionner correctement.

Marc

Answer 3

Vous pouvez également envisager la mise dans la chaîne de connexion un nom d'application unique plutôt que d'utiliser un utilisateur distinctif, que vous pouvez entrer dans votre clause where avec APP_NAME(). Je suis sûr que SQL Server n'aura pas de problème avec des milliers de connexions, mais vous préférerez peut-être ne pas avoir à les créer.