Discussion :

[Kropernic]

Bonjour,

Je me pose des questions quant aux bonnes pratiques des DB ayant plusieurs schémas.

J'utilise le schema dbo comme étant un schéma "fourre-tout" où se trouve les tables qui n'appartiennent à aucun schéma et à tous en même temps. Par exemple, la table des langues n'est pas du ressort du schéma S_HR ou S_OPERATIONAL mais ils en ont tous deux besoin. Pareil pour la table des magasins. Est-ce bien de faire cela ? Si non, que conseilleriez-vous ?

Dans le schéma S_HR (qui relève des ressources humaines), il y a bien sûr une table des employés. Dans un autre schéma, j'ai également besoin d'utiliser des employés. Puis-je faire référence directement à la table du schém S_HR ou bien est-ce mieux de créer une table dans ce 2e schéma avec héritage vers la table de S_HR ?
Je pense opter pour la création d'une nouvelle table dans le 2e schéma qui hérite de la première histoire de pouvoir lui ajouter des colonnes spécifique sans polluer la première table.

[SQL_EVAN]

Bonjour,

Tout dépend des règles de sécurité en place sur votre instance de SQL Server.

Bien sur vous pouvez faire des requêtes entre les schémas et mêmes de jointures. Après des fois, certains utilisateurs peuvent être restreints sur certains schémas.

Une pratique que je fais des fois est de mettre les tables des productions sur un schema BASE.prod.TABLE cela permet de publier des mises à jour sans couper la productions sur BASE.dbo.TABLE et puis d'écraser la table en prod en faisant un DROP TABLE et ALTER SCHEMA prod TRANSFER dbo.TABLE

C'est bien de penser aux schémas. Le plupart des utilisateurs de SQL Server les oublie

[Kropernic]

Bah, les règles de sécurité, c'est moi qui les décides XD.

Je cherche plutôt la bonne chose à faire au niveau "conceptuel" (j'trouve pas de meilleur terme même si on est clairement au niveau physique).

Niveau sécurité, toutes les "actions" DB des applications se font uniquement via des procédures stockées donc ça va...

[SQL_EVAN]

Je suis plutôt pour le développement fonctionnel (mais bien cadré et documenté niveau SI)

C'est-à-dire qu'il ne faut pas être trop contraignant afin de suivre à 100% les normes et bonnes pratiques mais il faut plutôt bien analyser son SI pour savoir quelles sont les meilleures pratiques à suivre et créer de la doc. Une fois vous avez créer vos normes et pratiques personnalisée vous pouvez les implémenter et faire en sorte que les autres développeurs suivent les mêmes normes et bonnes pratiques.

Je sais que cela ne répond pas à votre question mais ne connaissant pas votre SI nous serions pas en mesure de vous conseiller la meilleure mise en pratique.

Si vous avez des exemples pointus et détaillés nous pourrions surement vous aider.

Bon courage