DLDR: J'aimerais obtenir
- une confirmation de ma compréhension des espaces et des schémas (voir image)
- une recommandation Comment organiser des schémas et des espaces de table pour faciliter une séparation ultérieure.
Contexte: Dans notre projet, nous avons deux équipes différentes qui travaillent sur la mise en œuvre d'un site Web. L'idée est de séparer ultérieurement le basic-services
À partir de la fonction website (cms / portal)
afin que différents sites Web/portails puissent être créés, tous utilisent tous les mêmes indépendants basic-services
.
L'installation actuelle ressemble à ceci:
TABLESPACE_N MB AUTOEXTENSIBLE
FOOBAR_DATA 1024 YES
FOOBAR_INDEX 1024 YES
FOOBAR_LOB 1024 YES
SYSAUX 600 YES
SYSTEM 700 YES
TEMP 1024 NO
UNDOTBS1 456 YES
Ceci question concerne comment déplacer un schéma vers un autre espace de table . Certaines recommandations store indexes in another filesystem
Sont controversées/douteuses . Mais ce n'est pas la portée de ma question. Je voudrais obtenir une recommandation comment organiser le schéma et l'espace de table pour faciliter une séparation ultérieure.
Confirmation/Clarification: Mon ergo-annoncé d'Oracle est le suivant:
- tablespace: Unité de stockage logique, une ou plusieurs datafiles
- Datafiles: Structure physique conforme au système d'exploitation, un fichier de données peut être associé à un seul espace de table et une seule base de données
- schéma: une collection de structures logiques de données (table, index) ou d'objets de schéma (voir, ..), même nom que l'utilisateur db Cela le possède, chaque utilisateur possède un seul schéma. [Un utilisateur peut avoir accès à des objets de schéma détenus par différents utilisateurs.]
Dans l'image ci-jointe, vous pouvez voir deux schémas :
- schéma blanc
S1
- et schéma jaune
S2
Question 1:
- Je crois comprendre comment un schéma pourrait être organisé dans la base de données correcte?
- Nous pourrions donc créer deux schémas (/ deux utilisateurs) et séparer les objets du
FOOBAR-services
(Jaune) à partir du FOOBAR-website
(Blanc) de quelque manière que ce soit, nous voulons? [.____]- Schema 1 ne pouvait utiliser l'espace de table 1 avec Datafile 1 et 2?
- Schema 2 n'a peut-être pas pu utiliser de tablespace 2 avec Datafile 3?
Question 2:
Quelle structure recommanderiez-vous de faire une séparation ultérieure du FOOBAR-website
Et le FOOBAR-services
Très facile
- différents espaces de table pour
FOOBAR-Web
et FOOBAR-Services
? - chaque schéma dans son propre espace de table (ou n espaces)?
Je pense que vous avez fini de compliquer cela. Les subventions et les rôles régissent l'accès par les utilisateurs et non de l'espace de table et des fichiers de données où les données sont installées. Oui, la sauvegarde, la récupération et l'exportation sont beaucoup plus faciles si les schémas ont leur propre espace de table, mais cela ne semble pas être votre question.
- Séparez vos domaines d'affaires par utilisateur/schéma.
- Donnez à chaque utilisateur/schéma son propre groupe de tables de table contenant leurs tables/index/lobs, par exemple: user1data, user1indexes, user1lobs
- créer des rôles pour permettre aux utilisateurs/schemas d'accéder aux données/code dans d'autres schémas
De votre commentaire ci-dessous j'ajouterais:
- l'utilisateur/schéma sont le moyen logique de séparer les données et le code. Utilisez différents schémas du premier jour si votre domaine d'entreprise fonctionne de cette façon (et cela semble être ce que vous indiquez). Des tables en mouvement sur différents schémas après le déploiement peuvent être faites, mais c'est une douleur.
- dans votre commentaire, vous liez toujours des espaces de table et des autorisations. Il n'y a pas de lien entre l'espace de la table d'entretien des données d'un utilisateur et les autorisations accordées sur ces données.
Si vous me permettrez une simplification:
- les utilisateurs et les schémas vous permettent de contrôler l'accès aux données et au code via des rôles et des subventions.
- les espaces de table et les fichiers de données vous permettent de gérer les fichiers physiques utilisés par la base de données. La sauvegarde et la récupération plus faciles sont l'une des choses plus faciles à faire lorsque chaque utilisateur dispose de leurs données dans un ensemble clairement défini d'espaces de table.