Moștenire în baza de date?

Există vreo modalitate de a folosi moștenirea în baza de date (mai exact în SQL Server 2005)?

Să presupunem că am câteva câmpuri ca CreatedOn , CreatedBy pe care vreau să le adaug pe toate entitățile mele. Caut un mod alternativ, în loc să adaug aceste câmpuri la fiecare masă.

0
fr hi bn
adăugat autor jpalecek, sursa
Cred că întrebarea dvs. ar fi mai bine formulată ca "Care sunt modalitățile recomandate de a gestiona auditul într-o bază de date?"
adăugat autor Michael Brown, sursa
Dacă acesta este singurul scop, sunt de acord. Dar întrebarea db-iheritance este una bună
adăugat autor Steven A. Lowe, sursa

9 răspunsuri

Puteți crea un șablon în panoul de șabloane din Management Studio. Apoi, utilizați acest șablon de fiecare dată când doriți să creați un nou tabel.

În caz contrar, ați putea stoca câmpurile CreatedOn și CreatedBy într-o tabelă de traseu de audit referindu-se la tabela originală și ID.

Dacă nu reușiți, faceți-o manual.

0
adăugat
șabloanele nu sunt moștenire
adăugat autor Steven A. Lowe, sursa

Avem un SProc care adaugă coloane de audit într-un tabel dat și (opțional) creează o tabelă de istoric și declanșatorii asociați pentru a urmări modificările unei valori. Din păcate, politica companiei înseamnă că nu pot împărți, dar într-adevăr nu este dificil de realizat.

0
adăugat

Nu există niciun fel de moștenire între tabelele din SQL Server 2005 și, după cum au menționat ceilalți, puteți obține până la obținerea ajutorului adăugarea coloanelor necesare în tabele atunci când le creați, dar nu va fi moștenire ca și dvs. stiu.

Gândiți-vă mai degrabă la un șablon pentru fișierele cu cod sursă.

După cum menționează GateKiller, puteți crea un tabel care conține datele partajate și trimiteți-le unei chei externe, însă trebuie fie să aveți cârlige de audit, declanșatoare, fie să efectuați manual actualizarea.

Linia de fund: lucrare manuală.

0
adăugat
încercați să nu faceți referire la un alt post, deoarece acestea nu funcționează din cauza votării.
adăugat autor Michael Brown, sursa

PostgreSQL are această caracteristică. Doar adăugați acest lucru la sfârșitul definiției tabelului:

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

Tabelul copil va avea toate coloanele părintelui său, iar modificările la tabela parentală vor schimba copilul. De asemenea, totul din tabelul copil va apărea în interogări la tabela parentală (implicit). Din păcate indicii nu traversează frontiera părinte / copil, ceea ce înseamnă că nu puteți asigura că anumite coloane sunt unice atât pentru părinți, cât și pentru copii.

Din câte știu, nu este o caracteristică folosită foarte des.

0
adăugat
am crezut că întrebarea a spus "în mod specific în SQL Server 2005"?
adăugat autor Steven A. Lowe, sursa

în cartografiere O-R, hărți de mosteniri către o tabelă părinte, unde tabelele părinte și copil utilizează același identificator

de exemplu

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 are o relație cheie străină cu Object. atunci când creați un rând SubObject, mai întâi trebuie să creați un rând de obiecte și să utilizați Id-ul în ambele rânduri

0
adăugat

Dacă utilizați GUID-uri, puteți crea un tabel CreateHistory cu coloane GUID, CreateOn, CreatedBy. Pentru populația tabelului, va trebui să creați un declanșator pentru fiecare tabel sau să îl gestionați în logica aplicației.

0
adăugat
dacă tot ce ai este GUID, cum ai putea ști de la care tabelă a venit?
adăugat autor Steven A. Lowe, sursa

Nu doriți să utilizați moștenirea pentru a face acest lucru! Când tabelele B, C și D moștenesc de la tabelul A, înseamnă că interogarea tabelului A vă va da înregistrări de la B, C și D. Acum ia în considerare ...

DELETE DE LA a;

În loc de moștenire, utilizați LIKE în schimb ...

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

Ați putea utiliza un instrument de modelare a datelor, cum ar fi ER / Studio sau ERWin. Ambele instrumente au coloane de domenii unde puteți defini un șablon de coloană pe care îl puteți aplica în orice tabel. Atunci când domeniul se modifică, faceți și coloanele asociate. ER / Studio are, de asemenea, șabloane de declanșare pe care le puteți construi și aplica la orice tabel. Acesta este modul în care actualizăm coloanele LastUpdatedBy și LastUpdatedDate fără a trebui să construim și să menținem sute de scripturi de declanșare.

Dacă creați un tabel de audit, veți avea un rând pentru fiecare rând din fiecare tabel care utilizează tabelul de audit. Asta ar putea fi dezordonat. După părerea mea, ar fi mai bine să puneți coloanele de audit în fiecare tabel. Puteți, de asemenea, doriți să puneți o coloană a timestampului în toate tabelele. Niciodată nu știți când concurența devine o problemă. Coloanele noastre de audit pe care le punem în fiecare tabel sunt: ​​CreatedDt, LastUpdatedBy, LastUpdatedDt și Timestamp.

Sper că acest lucru vă ajută.

0
adăugat

Ramesh - Mi-aș implementa acest lucru folosind relații supertip și subtip în modelul meu E-R. Există câteva opțiuni fizice diferite pe care le aveți în legătură cu implementarea relațiilor.

0
adăugat