Critères de décision sur le moment d'utiliser un schéma non-dbo par rapport à une nouvelle base de données

Je suis principalement un développeur d'applications, mais je dois faire tout le travail de base de données initial pour mon projet actuel ( entre autres ... son MS SQL Server 2008 ). En tant que première décision, j'essaie de déterminer s'il faut diviser mon état en utilisant des bases de données séparées ou en utilisant des schémas séparés dans la même base de données. J'ai fait un peu de lecture sur les schémas SQL Server et cela semble être un moyen naturel de séparer les domaines d'objets ( ce que j'aime ), mais je ne sais pas s'il peut y avoir des coûts cachés à ce modèle.

Quelles sont les choses les plus pratiques à prendre en compte lors du choix entre ces deux approches? Si j'évite la dbo.mytablefaveur de, myschema.mytablevais-je créer d'autres défis ( ou problèmes ) pour mon architecture?

En guise de note ... À un moment donné, cela sera remis à un véritable DBA pour le maintenir / le soutenir, donc j'essaie de m'assurer que je ne leur rend pas la vie plus difficile.

Je commencerai par dire de ne pas considérer les schémas comme des espaces de noms ou des domaines d'objets au sens OO. Les schémas sont essentiellement des conteneurs d'autorisations avec une certaine valeur ajoutée (voir ci-dessous)

En outre, les «schémas séparés» ou les «bases de données distinctes» sont deux concepts différents. Les données qui doivent être transactionnelles et référentiellement cohérentes doivent se trouver dans la même base de données. Voir une base de données ou dix? article de blog pour en savoir plus.

Dans cette base de données, vous pouvez ou non utiliser des schémas pour organiser vos objets.

Personnellement, je suis fan des schémas et les utilise toujours, mais pour des choses comme les autorisations et le regroupement logique. Pour cela, je vous renvoie aux questions précédentes où vous pouvez voir que l'opinion générale y est favorable:

• Conception de schéma - meilleures pratiques?
• Quelle norme dois-je suivre pour nommer les tables et les vues?
• Surutilisation / utilisation correcte des schémas?

Pour le cas de bases de données distinctes, voir la réponse d'Aaron , mais tout cela dépend de l'exigence de "cohérence transactionnelle et référentielle".

D'accord avec @gbn. J'ai conçu des solutions utilisant des schémas de séparation et des bases de données pour la séparation, et je trouve que l'utilisation de bases de données est beaucoup plus pratique. Quelques raisons:

1. Faire en sorte que votre application se connecte à une base de données spécifique au contexte, puis exécuter les mêmes requêtes est beaucoup plus facile que d'injecter vos requêtes <schema>devant toutes les références d'objet. Cela se prête à beaucoup de SQL dynamique, à beaucoup de connexions d'applications différentes avec des schémas par défaut (ce qui signifie que votre code n'utilisera pas le préfixe de schéma, en s'appuyant sur le schéma par défaut de l'utilisateur de l'application - peut conduire à un gonflement massif du cache du plan et à un débogage difficile), ou beaucoup de procédures stockées à gérer (imaginez juste un simple rapport, si vous en avez besoin d'un par schéma, alors le code change, maintenant vous devez changer le même code plusieurs fois, une fois pour chaque schéma).
2. La séparation par base de données vous permet de déplacer des bases de données occupées vers un stockage / des instances plus rapides ou différents sans avoir à extraire des objets d'une grande base de données globale. La plupart des gens n'y pensent pas longtemps à l'avance, mais c'est certainement un problème d'échelle potentiel. Surtout si vous finissez par avoir un schéma qui "prend le relais" et nécessite la plupart des ressources sur le serveur, leur répartition peut être une tâche extrêmement lourde, même si elles sont déjà séparées par un schéma.
3. Des bases de données distinctes peuvent également vous permettre d'avoir des calendriers de maintenance et de sauvegarde différents pour chaque division. Je ne sais pas ce que vous entendez par "diviser par état", mais en supposant que vous entendez isoler les clients, vous pouvez avoir des clients avec des exigences différentes et une tolérance différente pour la perte de données, la maintenance d'index, etc.
4. Vous pouvez vous retrouver avec des clients qui, en vertu de la loi ou de la politique de l'entreprise, ont besoin de vous pour que leurs données soient séparées de toute autre personne. Ceci est généralement acceptable au niveau de la base de données, mais le niveau du schéma sera généralement insuffisant. Vous n'avez peut-être pas ces clients maintenant, mais cela pourrait devenir un vrai problème plus tard si vous le faites.