question de conception de base de données

Question

Je construis une base de données comme un simple exercice, il pourrait être hébergé sur n'importe quel serveur de base de données, alors j'essaie de garder les choses le plus standard possible. Fondamentalement ce que je voudrais faire est une table 'de code' qui est référencée par d'autres entités. J'explique:

xcode 
id code 
r role 
p property 

code 
r admin 
r staff 
p title 
.... 

alors je voudrais avoir une vue comme:

role (select * from code where xcode='r') 
r admin 
r staff 

property (select * from code where xcode='p') 
p title 

alors, supposons que nous avons une entité

myentity 
id - 1 
role - admin (foreign key to role) 
title - title (foreign key to property) 

Il est évident que je ne peux pas créer la clé étrangère à vue , mais c'est pour dire l'idée que j'ai en tête. Comment puis-je refléter un tel comportement en utilisant autant que possible, la syntaxe sql standard, puis en deuxième option, des fonctionnalités supplémentaires de base de données comme trigger ecc ...? Parce que si je dis que le rôle et le titre dans myentity sont des clés étrangères à 'code', à la place des vues, rien ne m'empêcherait d'insérer un rôle dans le champ title.

grâce Leonardo

Answer 1

J'ai travaillé sur des systèmes avec une seule table pour tous les codes et d'autres avec une table par code. Je préfère définitivement la dernière approche.

Les avantages d'une table par le code sont:

1. clés étrangères. Comme vous l'avez déjà remarqué, il n'est pas possible d'imposer la conformité aux valeurs autorisées via des clés étrangères avec une seule table. L'utilisation de contraintes de vérification est une approche alternative, mais son coût de maintenance est plus élevé.
2. Performances. Les recherches de code ne sont normalement pas un goulot d'étranglement, mais cela aide sans aucun doute l'optimiseur à prendre des décisions judicieuses sur les chemins d'exécution s'il sait qu'il récupère des enregistrements d'une table avec quatre lignes au lieu de quatre cents.
3. Groupes de codes. Parfois, nous voulons organiser un code en sous-divisions, généralement pour faciliter le rendu de listes de valeurs complexes. Si nous avons une table par code, nous avons plus de flexibilité quand il s'agit de structure.

En outre, je remarque que vous voulez être en mesure de déployer "sur n'importe quel serveur de base de données". Dans ce cas, évitez les déclencheurs. Les déclencheurs sont généralement de mauvaises nouvelles dans la plupart des scénarios, mais ils ont une syntaxe spécifique au produit.

Answer 2

Ce que vous essayez de faire est dans la plupart des cas un motif et anti erreur de conception. Créez simplement les différentes tables au lieu des vues.

Il existe de rares cas où ce type de conception est logique. Dans ce genre inclure le champ xcode dans la clé primaire/clé étrangère. Ainsi, votre entité ressemblera à ceci:

myentity 
id - 1 
role_xcode 
role - admin (foreign key to role) 
title_xcode 
title - title (foreign key to property) 

Vous pouvez alors créer des contraintes de contrôle pour faire respecter = de role_xcode « r » et title_xcode = « p »

(désolé, je ne sais pas si elles sont standard, ils existent en oracle et sont si simples que je les attendrais aussi sur d'autres rdbms)