Database Reference
In-Depth Information
Un serveur SQL (aussi appelé « instance ») est une machine logique installée sur un
ordinateur lui-même physique ou logique. La plupart des éditeurs permettent d'installer
plusieurs serveurs SQL sur une même machine. Dans chaque serveur SQL, il peut y avoir
plusieurs bases de données (limité à 32 000) et dans chaque base des schémas SQL (la
limite théorique étant 4 milliards par bases…) qui constituent autant d'espace logique,
dont le but est triple :
• fournir un moyen de ranger les différents objets en différentes catégories (par exemple,
un schéma pour les ressources humaines, un autre pour la comptabilité, un troisième
pour la production…) ;
• permettre d'associer des privilèges au niveau du schéma à des utilisateurs, ce qui
allège la tâche d'administration de sécurité pour les objets futurs (par exemple,
GRANT
SELECT ON SCHEMA::COMPTA TO DOMINIQUE
) ;
• autoriser dans un ordre
CREATE SCHEMA
de créer des objets mutuellement dépendants
sans pour cela se contraindre à un ordre logique particulier (voir http://blog.deve-
loppez.com/sqlpro/p5835/langage-sql-norme/de-l-interet-des-schema-sql/ et http://
docs.postgresqlfr.org/9.0/sql-createschema.html).
Il existe toujours un schéma par défaut pour la base et pour l'utilisateur.
En cas d'absence du préixe de schéma pour atteindre un objet, le serveur doit effectuer
une résolution de nom en commençant par chercher l'objet dans le schéma associé à
l'utilisateur, et s'il ne le trouve pas, le serveur l'associe au schéma par défaut de la base.
Dans tous les cas, cette phase prend du temps et peut conduire à des problèmes de pertes
de cache donc, de mauvaises performances. Il vaut donc mieux être précis et préixer tous
les objets de vos requêtes par le schéma dans lequel ils ont été créés.
MySQL n'implémente pas la notion de schémas SQL, mais laisse entendre que cela est
similaire à la création de multiples bases dans une même instance. Certains SGBD, en
particulier MS SQL Server et MySQL, autorisent nativement des requêtes interbases avec
des noms qualiiés (par exemple MaBase.MonSchema.MaTable pour MS SQL Server).
Pour faire cela, sous Oracle ou PostGreSQL, il faut recourir à un mécanisme de DBlink
qui semble plus lourd et moins performant.
Schémas SQL ou bases ?
Bien souvent, les développeurs se posent cette question cruciale : « Faut-il que je fasse
plusieurs schémas SQL ou est-il préférable de passer par plusieurs bases ? » Mais cette
question est idiote ! En effet, schémas et bases de données n'ont absolument pas le même
rôle et prendre l'un pour l'autre comme le fait MySQL peut s'avérer catastrophique à tous
les plans (logique, physique et administratif…).
