2008-08-08 9 views
8

Existe-t-il un moyen d'utiliser l'héritage dans la base de données (en particulier dans SQL Server 2005)?Héritage dans la base de données?

Supposons que j'ai quelques champs comme CreatedOn, CreatedBy que je veux ajouter toutes mes entités. Je cherche un moyen alternatif au lieu d'ajouter ces champs à chaque table.

+0

Je pense que votre question serait plus appropriée: «Quelles sont les méthodes recommandées pour gérer l'audit dans une base de données? –

+0

Si c'est le seul but, je suis d'accord. Mais la question db-iheritance est une bonne –

+0

Realted: http://stackoverflow.com/questions/386652/techniques-for-database-inheritance – jpalecek

Répondre

3

Il n'existe pas d'héritage entre les tables dans SQL Server 2005 et, comme indiqué par les autres, vous pouvez obtenir de l'aide en ajoutant les colonnes nécessaires aux tables lorsque vous les créez, mais cela ne sera pas le cas. être l'héritage comme vous le savez. Pensez-y plutôt à un modèle pour vos fichiers de code source. Comme le mentionne GateKiller, vous pouvez créer une table contenant les données partagées et les référencer avec une clé étrangère, mais vous devrez avoir des hooks d'audit, des triggers, ou faire la mise à jour manuellement.

Résultat: travail manuel.

+0

essaie de ne pas référencer un autre post car ils ne fonctionnent plus à cause des votes. –

1

Vous pouvez créer un modèle dans le volet de modèle dans Management Studio. Et puis utilisez ce modèle chaque fois que vous voulez créer une nouvelle table. A défaut, vous pouvez stocker les champs CreatedOn et CreatedBy dans une table de trace d'audit référençant la table et l'ID d'origine.

A défaut, faites-le manuellement.

+0

les modèles ne sont pas l'héritage –

3

PostgreSQL possède cette fonctionnalité. Il suffit de l'ajouter à la fin de votre définition de la table:

INHERITS FROM (tablename[, othertable...]) 

La table enfant aura toutes les colonnes de son parent, et les modifications à la table parent va changer l'enfant. En outre, tout dans la table enfant apparaîtra dans les requêtes à la table parent (par défaut). Malheureusement, les index ne traversent pas la frontière parent/enfant, ce qui signifie également que vous ne pouvez pas vous assurer que certaines colonnes sont uniques dans le parent et l'enfant. Pour autant que je sache, ce n'est pas une fonctionnalité très souvent utilisée.

+0

Je pensais que la question disait 'spécifiquement dans SQL Server 2005' ? –

0

Vous pouvez utiliser un outil de modélisation de données tel que ER/Studio ou ERWin. Les deux outils ont des colonnes de domaine dans lesquelles vous pouvez définir un modèle de colonne que vous pouvez appliquer à n'importe quelle table. Lorsque le domaine change, les colonnes associées le sont également. ER/Studio possède également des modèles de trigger que vous pouvez créer et appliquer à n'importe quelle table. C'est ainsi que nous mettons à jour nos colonnes LastUpdatedBy et LastUpdatedDate sans avoir à créer et à gérer des centaines de scripts de trigger.

Si vous créez une table d'audit, vous disposez d'une ligne pour chaque ligne de chaque table utilisant la table d'audit. Cela pourrait être désordonné. À mon avis, il vaut mieux mettre les colonnes de vérification dans chaque tableau. Vous pouvez également placer une colonne d'horodatage dans toutes vos tables. Vous ne savez jamais quand la concurrence devient un problème. Nos colonnes d'audit DB que nous mettons dans chaque table sont: CreatedDt, LastUpdatedBy, LastUpdatedDt et Timestamp.

Espérons que cela aide.

0

Nous avons un SProc qui ajoute des colonnes d'audit à une table donnée, et (facultativement) crée une table d'historique et des déclencheurs associés pour suivre les modifications apportées à une valeur. Malheureusement, la politique de l'entreprise signifie que je ne peux pas partager, mais ce n'est vraiment pas difficile à réaliser.

0

Si vous utilisez des GUID, vous pouvez créer une table CreateHistory avec des colonnes GUID, CreatedOn, CreatedBy. Pour remplir la table, vous devez toujours créer un déclencheur pour chaque table ou le gérer dans la logique de l'application.

+0

Si tout ce que vous avez est le GUID, comment sauriez-vous de quelle table il vient? –

0

Vous ne voulez PAS utiliser l'héritage pour cela! Lorsque les tables B, C et D héritent de la table A, cela signifie que l'interrogation de la table A vous donnera des enregistrements de B, C et D. Considérez maintenant ...

DELETE FROM a;

Au lieu de l'héritage, utiliser à la place ... COMME

CREATE TABLE blah (
    blah_id  serial  PRIMARY KEY 
    , something text   NOT NULL 
    , LIKE template_table INCLUDING DEFALUTS 
); 
0

Ramesh - je mettre en œuvre cette aide de relations et de supertype sous-type dans mon modèle E-R. Vous disposez également de différentes options physiques pour implémenter les relations.

0

dans la cartographie O-R, des cartes d'héritage à une table parent où les tables parent et enfant utilisent le même identifiant

par exemple

create table Object (
    Id int NOT NULL --primary key, auto-increment 
    Name varchar(32) 
) 
create table SubObject (
    Id int NOT NULL --primary key and also foreign key to Object 
    Description varchar(32) 
) 

Subobject a une relation de clé étrangère à l'objet. Lorsque vous créez une ligne SubObject, vous devez d'abord créer une ligne Objet et utiliser l'ID dans les deux lignes.

Questions connexes