Le schéma dbo doit-il être évité?

En ce qui concerne le schéma dbo:

• Est-il recommandé d'éviter d'utiliser le schéma dbo lors de la création d'objets de base de données?
• Pourquoi le schéma dbo devrait-il être évité ou devrait-il l'être?
• Quel utilisateur de base de données doit posséder le schéma dbo?

Cela peut être une bonne pratique car lorsque d'autres utilisateurs utilisent la base de données, vous souhaitez pouvoir limiter leur accès avec des schémas. Par exemple, dans une base de données, vous disposez des tableaux suivants.

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

En tant que directeur des ressources humaines, je peux accéder à tout dans le HRschéma, en tant que ITdirecteur, je peux voir les noms d'utilisateur et les niveaux d'accès des employés. Le Engineeringdépartement peut voir quels sites d'emploi sont actifs, etc. Si dbo était le schéma défini pour toutes les tables, j'aurais plus de mal à segmenter mes données et à fournir des rôles d'accès.

L'idée, je crois, dans SQL Server est d'offrir un produit accessible et interrogé par différents services. En réalité, seuls les DBA / DBDev accèdent réellement à la base de données et elle ne stocke généralement que les données d'application.

Il aide également à la lisibilité et à la gérabilité. À première vue, je peux facilement identifier quelle table contient quelles données et comment les données sont séparées.

Personnellement, je préfère définir les schémas comme une pratique générale. N'oubliez pas que le schéma est grec pour le plan, avoir une structure de schéma présentée vous aide à planifier et à identifier les données.

Je pense que cela dépend vraiment de la préférence des utilisateurs car il n'y a pas de véritable raison technologique pour le faire. En fait, par souci de simplicité, je dis toujours utiliser dbo à moins que vos exigences de sécurité ne le stipulent autrement. Bien sûr, vous pouvez toujours le faire uniquement à des fins d'organisation.

Si quoi que ce soit, dbo doit être évité car c'est la valeur par défaut pour SQL Server, il n'est également pas du tout descriptif. Comme tous les autres noms par défaut, comme il est connu à l'avance, cela rend la vie d'un pirate beaucoup plus facile (bien que s'ils sont au point où ils essaient juste de comprendre le nom de votre schéma, vous êtes probablement déjà borked).

Là où je travaille, nous utilisons des schémas pour diviser la base de données en sections logiques et attribuer des autorisations aux schémas.

Par exemple, nous pouvons avoir un système d'inventaire avec une base de données. Les tables principales peuvent être dans le schéma inv. Si nous importons quelque chose dans la base de données, un schéma de transfert serait utilisé dans le cadre du processus d'importation. Si nous avons des procédures stockées système auxquelles les utilisateurs n'ont pas besoin d'accéder, nous les mettons dans un schéma sp.

Ce n'était pas auparavant la meilleure pratique car les schémas étaient masqués avant SQL 2005, tout était placé dans le schéma dbo. L'équipe SQL Server l'a présentée comme une meilleure pratique et a publié un article à ce sujet: Meilleures pratiques SQL Server - Implémentation des schémas d'objet de base de données

En ce qui concerne votre autre question concernant qui devrait en être propriétaire: le schéma dbo appartient au compte utilisateur dbo.