Est-ce une bonne idée de diviser mes objets SQL Server en schémas basés sur leur regroupement logique (un type d'espace de noms, ventes, utilisateur, commun) ou devraient-ils être principalement utilisés pour créer différentes limites de sécurité?Les schémas de serveur SQL doivent-ils être utilisés pour le regroupement logique ou administratif?
Je voudrais opter pour le groupement logique et définir la sécurité via des rôles. mais généralement les groupes logiques et de sécurité sont les mêmes. en général :)
Vous pouvez placer des procédures stockées dans des schémas en fonction du niveau de sécurité. Accordez ensuite l'exécution sur le schéma à un rôle. Plus de subvention.
Le nouveau projet Microsoft appelé "Oslo" utilise des schémas pour regrouper des objets dans des espaces de noms.
Je ne ferais peut-être que séparer les objets utilisateur des objets application/système. Autrement dit, les commandes, les produits, etc. sont des objets utilisateur. Les tables de sécurité sont des objets système. À un certain point également, il se peut que vous ayez un chevauchement d'autorisations si vous accordez des droits au schéma (comme suggéré). Ou vous pouvez ne pas être en mesure de classer un objet, ou il est utilisé dans différents domaines.
Si vous suivez les bonnes pratiques depuis bien avant SQL 2005 et que vous les avez mises à niveau, vous pouvez avoir des centaines de bases de données dans lesquelles chaque référence d'objet est qualifiée de schéma avec "dbo". Est-ce que vous divergez vos conventions de nommage pour les nouvelles bases de données, et peut-être casser tous vos scripts utiles qui s'appuient sur "dbo."?
Edit: Si vous décidez de faire cela, méfiez-vous des ownership chaining
+1. Bonne réponse, surtout en ce qui concerne le chaînage de propriété. Je connais un projet où cela a causé un sérieux chagrin. –