Adatbázis tábláinak létrehozási sorrendje, domain-ek, megszorítások

Adatbázis: SQL, XML DB

Kinek milyen tapasztalata van az adatbázis tábláinak létrehozási sorrendjét illetően, vagy milyen elveket követ?
- Logikai sorrend: Követi a hivatkozásokat, először a hivatkozott táblákat kell létrehozni. Kevés 

ALTER TABLE

-re van szükség.
- Név szerinti sorrend: A tábladefiníciók könnyen megtalálhatók, de a hivatkozások miatt sok 

ALTER TABLE

-re van szükség.

Ki részesíti előnyben a domain-ek alkalmazását? pl: 


create domain dolgozonev as varchar(40)
    constraint a_dolgozó_neve_nem_lehet_üres
        not null
    constraint a_dolgozó_neve_legalább_4_nem_szóköz_karakterből_álljon
        check (length(trim(both ' ' from value)) > 3);
  • 1971 megtekintés

( uid_194 | 2010. 11. 29., h – 15:29 )

En altalaban transactionben hozom oket letre, akkor teljesen mindegy, milyen sorrend (egyebkent logikai). Vagy ha nem en hozom letre kezzel, akkor az ORM-re bizom, es nem erdekel mikent csinalja.

( samu.ferenc | 2010. 11. 29., h – 18:20 )

Lehet, hogy csak én nem értem, de ennek mi a gyakorlati jelentősége?

Annak mi a gyakorlati jelentősége, hogy logikai vagy név szerinti sorrendet használ valaki a táblák létrehozásához.

Ami a domain-eket illeti, én nem szeretem használni őket, az adatbevitel ellenőrzése nem az adatbázis feladata, mármint a fenti példa szerinti. Természetesen a foreign key, unique, ... más lapra tartozik.

A névszerinti sorrend (uram bocsá' ahogy jön sorrend) sok(fölösleges) ALTER TABLE sort igényel a tábladefiníciók végén. Én a logikai sorrend híve vagyok, így már a tábladefinícióknál létrehozható a kapcsolat.
Ennyi. Csak érdekelt mások véleménye, szokása.

A fenti domain példa tényleg túl egyszerű, de mondjuk egy vonalkód ellenőrzése már egy gondolattal összetettebb.
Meg aztán könnyen előfordulhat, hogy egy tulajdonság hossza kezdetben 15 karakter, de később rájössz, vagy rájönnek, hogy mégis inkább 16 karakter hosszú legyen. Ilyenkor csak a domainben kell javítanom....
Ez is csak egy kérdés volt, mások szokásait illetően.

Az adatbevitel ellenőrzés utolsó védvonala az adatbázis sor-, vagy táblamegszorításai.
Főleg akkor, ha az adatbázis és a felhasználói felület készítése nem egy kézben történik.
Az üzleti folyamatok megismerése után elkészítik az adatbázis modelljét, majd magát az adatbázist és annak teljes dokumentációját. Ezt átadják a felhasználói felületet készító csapatnak. Ők aztán vagy megírják az adatbevitelt ellenőrző eljárásokat, vagy nem. De ebben az adatbázis készítői nem bízhatnak vakon. (szerintem)

gy

Sorrend: Program generálja, logikai szerint készíti

Domain: Az egységes mező tulajdonságok változtatása valóban hasznos
Ellenőrzés: Az üzleti réteget én inkább programban valósítom meg.
"vonalkód ellenőrzése már egy gondolattal összetettebb", valóban és pont emiatt, hol húzod meg a határt? Egy EAN13-mat még az adatbázis ellenőriz, de egy QR kódost már a program? Az adatbázis feladata az én meglátásom szerint annyi, hogy a kapott adatot tárolja le.

( siposa v | 2010. 11. 29., h – 18:38 )

Modellezővel készítek szkriptet, logikai sorrendben generálja a parancsokat.