Notion de schéma

Bonjour a tous,

De ce que je comprends la notion de schéma est fondamentale a la création d'une BDD, mieux vaut éviter créer des tables sur le schéma dbo.

2 choses que je ne comprends pas :
Le schéma est un conteneur, pourquoi devrais-je créer plusieurs schémas. Faut il réfléchir en business, en catégorie de données, c'est quoi les best practice ?

Comment est ce que je fais si j'ai des tables communes à plusieurs schémas pour maintenir une cohérence des données ? De ce que je comprends [schema_a].[table_a] n'est pas le même objet que [schema_b].[table_a].

effectivement laisser tout dans un même schéma est absurde, de même qu'utiliser le schéma par défaut dbo.

Une base peut contenir autant de schéma qu'on le souhaite pour organiser les objets de sa base (tables, vues, procédures, fonctions...).
Le but étant de facilité :

• la sécurité : on peut sécuriser de manière générique l'ensemble des objets d'un schéma (objets actuels et futurs)
• la modularité : recherche une table parmi 500 est moins facile que de recherche une table parmi 50, parce que la base aura été découpé en 10 schémas...

Dans la pratique on créé des schémas par rapport à deux axes :

• l'axe fonctionnel "metier" : par exemple ventes, stock, production, comptabilité...
• l'axe technique (DBA) : objets communs, objets d'admin, référentiel...

À me lire :
https://blog.developpez.com/sqlpro/p...des_schema_sql
https://blog.developpez.com/sqlpro/p..._et_utilisateu
§ "Privilégier les SCHEMA SQL"


A +

Donc il ne faut pas dupliquer des tables "communes" dans plusieurs schémas, si je comprends bien ? Il vaut mieux créer un schéma nommé "common" dans lequel je retrouve ces tables ...

Citation:

---

Envoyé par Pfeffer

Donc il ne faut pas dupliquer des tables "communes" dans plusieurs schémas, si je comprends bien ? Il vaut mieux créer un schéma nommé "common" dans lequel je retrouve ces tables ...

---

Évidemment. Si ces tables sont du référentiel ouvert, vous pouvez donner au rôle "public" les privilèges adéquats pour que tous les utilisateurs puissent y accéder :

Code:

---

GRANT SELECT ON SCHEMA::public;

---

Si vous voulez que tous les utilisateurs puissent les lire et les modifier :

Code:

---

GRANT SELECT, INSERT, DELETE, UPDATE, REFERENCES ON SCHEMA::public;

---

Sinon, il faudra le faire, utilisateur par utilisateur, ou par le biais de rôle que vous devrez créer.

A +

Et pourquoi est il déconseillé de tout mettre dans le schéma dbo ?
Si on part du principe que la base que l'on gère ne concerne qu'un businness et que les droits sont les mêmes pour tout le monde.

Ne serait ce que pour une raison de sécurité.

C'est comme le compte foot de Linux... Tout le monde sait qu'il existe et donc les hzvkers s'en donne à cœur joie parce qu'ils savent déjà la moitié de l'info...

Personnellement je déconseille totalement l'usage de dbo comme schéma.

Après séparer le référentiel des données métiers est important ne serait ce que par rapport au rgpd

Vous avez une obligation de tracer tous les accès aux données sensibles (personnelles) et en créant un schéma pour cela vous pouvez le faire globalement au niveau du schéma ce qui ne prendra pas en compte le référentiel que vous aurez créé dans un autre schéma.

Ce n''est qu un exemp' e parmi d'autres... il faudrait vous former... mon livre peut vous y aider...

Le livre je l'ai ... il faut que je fasse mes armes maintenant ... SQLServer c'est très puissant par contre maitriser la totalité des concepts c'est pas évident.

En fait le plus difficile c'est d'arbitrer entre plusieurs solutions alors qu'on a pas suffisament de recul sur toutes les solutions possibles.

Tout à fait.... D'où l'utilité des forums en sus des livres !

Aujourd'hui SQL Server est plus puissant qu'Oracle qui a longtemps été considéré comme le leader....
mais qui dit puissance dit complexité.
Heureusement SQL Server est nettement moins complexe qu'Oracle !

N'hésitez pas à poser des questions pour éviter d'aller dans la mauvaise direction !

A +