Bases de données séparées vs schémas

Il existe quelques raisons "pro" et "contra" d'utiliser les schémas ou les bases de données séparées gérées par la même instance du SGBD.

Bases de données (BD) séparées

  • Pro
    • Efficace si les liens entre les entités sont faibles et non pas
      nombreuses
    • Isolement des utilisateurs et développeurs au niveau de la BD
    • Les plans de maintenance différents sont disponibles facilement
    • Niveau supplémentaire (BD) pour l'espace de noms
  • Contra
    • Intégrité référentiel déclarative devrait être remplacé par les
      triggers en cas commun
    • Risque d'anomalie au cause des paramètres différentes des BD, par
      exemple, les collations et la casse de caractères, le niveau d'isolement
      des transactions accepté
    • Procédure de déploiement plus complique
    • Requêtes quasi-hétérogènes : il faut spécifier le nom complète
      d'objet inclus le nom de la BD et le schéma
    • Administration et maintenance : les charges supplémentaires
      (sauvegardes et plans de maintenance séparés, duplication des
      utilisateurs, stockage physique séparé etc.)

Schémas

  • Pro
    • Efficace si les liens entre les entités sont fort et/ou nombreuses
    • Isolement des utilisateurs et développeurs au niveau du schéma de la
      même base de données est suffisante dans plusieurs cas
    • Une seule liste d'utilisateurs pour accéder à tous les schémas et
      objets de la base de données
    • Administration et maintenance d'une seule base de données
    • Peut être plus performante au cause du cache partagé au niveau bas
      des objets de la base de données
  • Contra
    • Plus difficile d'implémenter les stratégies de sécurité et plans de
      maintenances différentes
    • Évolutive réduite : en cas de nécessité la décomposition sur
      plusieurs bases de données sera très impactée à tous les niveaux
    • Modularité réduite : plus difficile d'implémenter les packages
      qui n'utilise que certaines nombres des schémas et objets