Dotaz: Navrh databaze

[jirka]

Zdravim potreboval bych pomoct s navrhem DB. Mam entitu Auto, ktera obsahuje atributy jako vin, rok vyroby atd. Pak mam Entitu karoserie, ktera je jen vycet typu karoserie (Kombi, SUV,...).

Prvni navrh: Entita karoserie ma primarni klic jehoz id je poskytnuto entite Auto. Coz mi prijde zbytene a proto bych volil spise druhou moznost.

1/
+-----------------+         +-------------------+
|  Auto           |         | Kasoresie         |
+-----------------+         +-------------------+
| PK Vin int      |         | PK id Int         |
| RokVyr varchar  |         | Jmeno Varchar(25) |
| FK TypKaroserie |--------<|


2/
+-----------------+         +--------------------------+
|  Auto           |         | Kasoresie                |
+-----------------+         +--------------------------+
| PK Vin int      |    +---<| PK Uni Jmeno Varchar(25) |
| RokVyr varchar  |    |
| FK TypKaroserie |----+

Ve druhe moznosti vydim hlavni problem pri zmene nazvu. Respektive v pripade kdy mam v selectu left join (plati pro prvni pripad) tak zmenim jen nazev Karoserie u ID a ve vysledku selectu mam hotovo. V druhem pripade by tato moznost nebyla a pri zmene nazvu by byla stracena navaznost starych nazvu.

Snad sem to popsal srozumitelne. Dekuji predem za podmety a navrhy. Teprve se ucim tak me prosim nekamenujte za nepresnosti. Kazdy jednou musel zacit ;)

---

---

Odpovědi

[dustin]

Pokud jsem to dobře pochopil a rozdíl mezi 1 a 2 jen v tom, že 1 má id karosérie jako klíč tabulky i klíč vazby na auto, pak samozřejmě 1. Přece nebudeš spojovat tabulky stringovým názvem karoserie.

[Tarmaq]

Pouzil bych variantu 1/ jen s tim rozdilem, ze bych nemel umelohmotnej primarni klic typu INTEGER, ale dal bych tam VARCHAR. Tedy hodnoty v danem cisleniku by pak byly nejak takto:

+---------+------+
|id       |name  |
+---------+------+
|kombi    |Kombi |
|suv      |SUV   |
|sedan    |Sedan |
+---------+------+

Pokud bys pak chtel mit na FE u kombiku napsano napr. "Vagon", staci pak zmenit jen name u Karoserie.

[jirka]

ok super dekuji za podmety - pujdu cestou 1.
Co se tyce "umelohmotnej PK" neni lepsi z duvodu rychlosti puzivat cisleny PK, i kdyz umelohmotnej, misto Strigoveho? Dekuji za objsaneni.

[Tarmaq]

Tak INT bude mozna o malo rychlejsi, ale ten rozdil nebude tak vyrazny. Vyhodou stringoveho bude lepsi citelnost dat v tabulkach, neni potreba uziti konstant v kodu, atp.

[Josef Kufner]

Ta čitelnost v databázi celkem hodně pomůže a navíc to ID je pak často vidět i v URL při přístupu k daným entitám. A pokud nejde o statisíce řádků, opravdu bude rozdíl ve výkonu sotva znatelný.

[Filip Jirsák]

Ta čitelnost v databázi nebo dokonce URL znamená, že se z umělého klíče stal klíč přirozený a při změně názvu bude potřeba změnit i to ID. Protože mít v databázi záznamy

ID    | Nazev
-------------
jeep  | SUV
jeep2 | jeep

to čitelnosti v databázi vůbec nepomůže, právě naopak. Čitelnosti v databázi pomůže, pokud člověk není líný napsat JOIN. ID v URL je prasárna, pokud to není součástí API – například obvykle budete chtít povolit více URL pro jednu entitu (aby URL zůstalo platné i po přejmenování).

[Josef Kufner]

Záleží na aplikaci a na povaze dat v ní. Čitelnost URL je užitečná například při pohledu do logu, neboť tam se join dělá těžko. ID ve tvaru jeep1 a jeep2 je na prd, ale pokud to je například číslo místnosti nebo login uživatele, tak to velmi usnadní orientaci v datech při přístupu přes obecné nástroje. Změnu takového ID napříč celou databází pak snadno zajistí správně udělané cizí klíče s cascade při změně.

Zda ID v URL je či není prasárna hodně závisí na aplikaci. A často to sice prasárna být může, ale při tom to nemusí vůbec ničemu vadit a jen by se to zbytečně komplikovalo.

[Filip Jirsák]

Pokud je ID číslo místnosti nebo login uživatele, už to není umělý klíč a asi nebudete mít v tabulce vedle sebe dva sloupečky „ID“ a „login“, ve kterých budou stejné hodnoty. To popisujete tu druhou variantu, o které tazatel psal, tedy udělat primární klíč přímo z názvu. Ano, také je to možnost, nicméně v tomto případě je podle mne vhodnější umělý primární klíč, protože u toho názvu bude problém s trvalým zajištěním všech potřebných předpokladů. Třeba unikátnost – při návrhu vám samozřejmě všichni odsouhlasí, že název je a vždy bude unikátní, protože přece jak by to lidi rozlišili, kdyby se to jmenovalo stejně. První požadavek na duplicitní název pak přijde nejpozději do týdne od spuštění ostré verze.

[jos]

na jirsáka bacha, radši už na něj nereaguj, relačním databázím naprosto nerozumí, v uvedenejch diskuzích ho najdeš pod nickem Fa & Bi

[kukacka]

A jeste pro uplnost potencialni nevyhody stringoveho klice. Nelze pouzit sekvence/autoincerement. Pri zalozeni noveho zaznamu je treba klic zadat (kdo - uzivatel aplikace?). Existuji "frameworky" nad umelymi klici, ktere predpokladaji, ze je to cislo. Samozrejme nic z toho nemusi byt v konkretnim pripade problem, ale je dobre o tom vedet.

[Xerces]

Tak že by se konečně ministerstvo rozhoupalo přepsat ten registr vozidel?

[Milan Uhrák]

jj, už se na tom vážně pracuje, jak vidíte .. poslední ladění návrhu