Surutilisation / utilisation correcte des schémas?

Après avoir posé cette question sur Stackoverflow , je me suis demandé où ce que j'ai fait est correct / meilleure pratique.

Fondamentalement, chaque objet que je crée entre dans un schéma dont le nom de schéma reflète une utilisation. Par exemple, j'ai les schémas Auditet Admin(entre autres).

Ceci à son tour ne laisse aucun objet dbo. Est-ce correct? Y a-t-il autre chose que je dois faire?

Les schémas sont non seulement un excellent outil de sécurité (ce qui est une raison suffisante pour les utiliser), mais ils sont également parfaits pour la séparation logique. Et il semble que c'est ce que vous pratiquez.

Même si l'exigence actuelle n'a pas besoin d'une sécurité particulière, dites en bas de la route que tous les objets de base de données liés à l'audit doivent être sécurisés à un rôle de base de données. Si ces objets étaient dispersés dans le dboschéma, vous devrez alors explicitement disposer d' denyautorisations sur les objets individuels. Mais avec le Auditschéma, vous faites un single denyet vous êtes prêt.

Je pratique personnellement l'utilisation des schémas. Comme pour tout ce qui se trouve dans les bases de données, il existe un juste milieu. Je ne créerais pas de schéma pour chaque aspect granulaire de la couche de données. Il y a trop de schémas et de séparation. Mais je suppose que vous n'êtes pas près de cela.

Un schéma typique est des schémas basés sur des autorisations, donc vous auriez WebGUI, Desktopetc. pour le code afin que tous les objets aient les mêmes permissions du schéma .

Si vous avez des groupes d'utilisateurs clairs, vous pouvez autoriser cela, mais vous vous retrouverez avec des autorisations qui se chevauchent et qui sont en désordre à un moment donné. J'ai tendance à reporter les vérifications utilisateur / groupe à une vérification dans le code et non aux objets autorisations: disons que vous avez des utilisateurs Admin et HR Excel: ils exécutent tous du Desktopcode.

Les données sont généralement partagées, donc j'aurais un Dataschéma, peut-être un schéma Historyou Archive.

Certains codes ne sont pas publics (comme un UDF ou un processus interne), donc j'utiliserais un Helperschéma pour du code qui ne devrait pas être exécuté par le code client.

Enfin, les schémas comme Stagingou Systemou Maintenancesont parfois utiles.

Bien qu'il n'y ait aucun objet utilisateur dans le dboschéma, l'utilisateur dbopossède tous les schémas.

Aucun objet dans le dboschéma ne convient parfaitement. D'après ce que je peux voir, ce n'est pas non plus une surutilisation des schémas - bien que le nombre de schémas soit «trop» est une question assez subjective (c'est comparable à «combien de classes ma conception OO devrait-elle avoir?»).

La seule autre chose que je mentionnerais serait d'accorder des autorisations sur le schéma plutôt que sur des objets individuels (votre question SO ne spécifie rien sur les autorisations).

Je voudrais utiliser des schémas pour séparer la base de données en fonction des modules et des modèles d'utilisation. Je trouve que cela rend très facile à comprendre les tables de base de données, donc la maintenance devient plus facile. J'ai eu les types de schéma suivants dans mon dernier projet de serveur SQL. LT - Tables de recherche

COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

Pour un gros modules, nous les avons également séparés en plusieurs schémas. Par exemple, le module personnel comprend plus de 5 modules.

PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

Nous avons également inclus des schémas comme pour d'autres activités TEMP, MAINTANENCE. Dans le studio de gestion, vous pouvez filtrer à l'aide du nom de schéma. Un développeur responsable de MODULE1, filtre par nom et travaille presque tout le temps avec seulement ces tables. Cela permet aux développeurs, aux dbas et aux nouveaux venus de comprendre très facilement les tables de base de données.

Les meilleures pratiques peuvent être différentes pour le serveur SQL que pour Oracle, mais mon expérience est que moins il y a de schémas, mieux c'est.
J'aime avoir un schéma pour le dba / programmeur qui a des privilèges spéciaux et du code pour faire la maintenance. Toutes les données d'entreprise doivent être regroupées dans un seul schéma afin que vous sachiez où elles se trouvent. Les conventions de dénomination sont suffisantes pour différencier l'utilisation de la table ou du code stocké.
Je peux voir un cas où vous avez plusieurs unités commerciales devant des données différentes avec peu de chevauchement, chacune ayant son propre schéma. Sinon, restez simple.