Vous pouvez créer un modèle dans le volet des modèles de Management Studio. Ensuite, utilisez ce modèle chaque fois que vous souhaitez créer un nouveau tableau.

À défaut, vous pouvez stocker les champs CreatedOn et CreatedBy dans une table de piste d'audit faisant référence à la table et à l'ID d'origine.

À défaut, faites-le manuellement.

PostgreSQL possède cette fonctionnalité. Ajoutez simplement ceci à la fin de votre définition de table :

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

La table enfant aura toutes les colonnes de son parent, et les modifications apportées à la table parent modifieront l'enfant. De plus, tout ce qui se trouve 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 à la fois pour le parent et l'enfant.

Pour autant que je sache, ce n'est pas une fonctionnalité très souvent utilisée.

Il n'y a pas d'héritage entre les tables dans SQL Server 2005, et comme l'ont noté les autres, vous pouvez aller jusqu'à obtenir de l'aide pour ajouter les colonnes nécessaires aux tables lorsque vous les créez, mais ce ne sera pas l'héritage tel que vous le connaissez.

Considérez-le plutôt comme un modèle pour vos fichiers de code source.

Comme GateKiller le mentionne, vous pouvez créer une table contenant les données partagées et la référencer avec une clé étrangère, mais vous devrez soit avoir des crochets d'audit, des déclencheurs, soit effectuer la mise à jour manuellement.

Conclusion : travail manuel.

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 où 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 changent également. ER/Studio propose également des modèles de déclencheurs 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 à maintenir des centaines de scripts de déclenchement.

Si vous créez une table d'audit, vous auriez une ligne pour chaque ligne de chaque table qui utilise la table d'audit. Cela pourrait devenir désordonné. À mon avis, il vaut mieux mettre les colonnes d'audit dans chaque tableau. Vous pouvez également ajouter 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.

J'espère que cela vous aidera.

Nous avons un SProc qui ajoute des colonnes d'audit à une table donnée et (éventuellement) 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.

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

Vous ne voulez PAS utiliser l'héritage pour faire 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...

SUPPRIMER DE a ;

Au lieu de l'héritage, utilisez LIKE à la place...

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

Ramesh - J'implémenterais cela en utilisant des relations de supertype et de sous-type dans mon modèle E-R. Vous disposez également de différentes options physiques pour mettre en œuvre les relations.

dans le mappage O-R, l'héritage correspond à 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 avec Object. lorsque vous créez une ligne SubObject, vous devez d'abord créer une ligne Object et utiliser l'Id dans les deux lignes