Pourquoi les utiliser ?
Quand les utiliser ?
Comment les utiliser ?
Pourquoi les utiliser ?
1 Pour accélérer les requêtes : Précisez toujours nominement le schéma de l’objet, c’est encore mieux avec une collation binaire de votre base.
2 Si vous n’utilisez pas Power AMC, vous pouvez utilisez un schéma pour supprimer l’ordre dans la création des objets, par exemple, à l’intérieur d’un schéma, il est tout à fait envisageable de créer une vue avant les tables dont elle depend. Personnellement, je préfère que Power AMC crée les objets dans l’ordre.
3 Si vous utilisez des tables ayant un même nom pour une raison fonctionnelle, placez les dans un schéma de nom différent et nommez précisement le schéma avant chaque utilisation pour éviter toute équivoque.
4 Sur une grande base, les schémas simplifie la lecture et la compréhension de la base en découpant en domaine fonctionnels.
Quand les utiliser ?
Lorsque l’on regarde une application comme AdventuresWorks de Microsoft, on la comprend mieux grâce à l’utilisation de plusieurs schémas.
Le schéma est l’équivalent d’un namespace, d’un espace de nom sous .net avec une limitation de taille, il n’y a q’un seul niveau en SQL.
Personnellement, je n’ai pas encore développer un produit de plus de 50 tables dans des domaines fonctionnels différents, justifiant de passer du schéma dbo vers plusieurs schémas.
Comment les utiliser ?
Power AMC semble gérer cet aspect si vous devez le mettre en place.
Je confirme que PowerAMC gère bien cela.
J’ai été amené à mettre en place et utiliser plusieurs schémas sur une application de taille importante à destination d’une population hétérogène de 2 types d’utilisateurs (avec 2 systèmes d’informations jumeaux synchronisés partiellement par un EAI). Il y avait une notion de visibilité macro qui nécessitait d’avoir des entités propres à la première catégorie, à la seconde catégorie, et parfois aux deux (notion de partage). On peut donc y observer une table TOTO identique dans jusqu’à 3 schémas différents (il n’était pas envisageable de rajouter une colonne technique dans une unique table car cela complexifiait le mécanisme de synchronisation des 2 systèmes et était risqué sur l’aspect « séparation des données »).
Derrière (je ne saurai dire si cela est spécifique Oracle puisque c’est le SGBD cible utilisé) nous avions également des « users » applicatifs correspondant aux 2 catégories d’utilisateurs pour lesquels nous avons créé soit des synonymes, soit des vues, afin de masquer la complexité inhérentes aux schémas sous-jacents (et surtout leur restreindre à des droits DDL pour empêcher des créations/modifications/suppressions des tables).
Dans mes souvenirs, j’avais pu tout gérer avec PowerAMC (users=schemas, tables, droits, synonymes, vues, séquences, contraintes, index, clauses de stockage parfois très fines) sauf les triggers sur vues/tables et procédures stockées pour lesquels l’outil manquait de flexibilité et de valeur ajoutée, et les tablespaces (choix du DBA).