Identifying a non-Identifying relationships

1. 6. 2012 21:18:13

Ahoj,

právě řešíme s kolegou následující problém. Vztah identifying a non-Identifying relationships mez itabulkami. Na googlu jsem se dočetl, že se jedná například o vztah:

Kniho má právě jednoho autora a nemůže bez něj existovat
Smlouva je podepsána jedním člověk
Telefoní číslo pro jednu pevnou linku
atd.

... kdy potomek závisí na existenci rodiče a bez rodiče nemůže existovat.

Do teď jsem byl zvvyklý používat v těchto vztazích sekundární klíče a celkem dobře to fungovalo. Jaký výhody má tedy použít dva primární klíče z nichž bude jeden primární klíč primárním klíčem rodiče a druhý primárním klíčem potomka? Urychlí to nějak vyhledávání v tabulce. Jak se bude chovat potomek když se smaže rodič, atd.?

1. 6. 2012 21:18:13

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770793

(20 hodnocení)

1. 6. 2012 21:28:26

jak myslis dva primarni klice? primarni klic na tabulce muze byt jen jeden...

vztah autor<->knihy je relace 1:N tabulky tedy budou

AUTORI

id- primarni klic, autoincrement //znamena id autora

jmeno

KNIHY

id - primarni klic, autoincrement //znamena id knihy

id_autor - index, foreign key na autori->id //znamena id pod kterym je kniha prirazena - ON DELETE/UPDATE CASCADE tedy v podstate pri smazani autora zmizi kniha

nazev

popsal jsemto dost technicky, takze ocekavam dotazy

1. 6. 2012 21:28:26

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770792

Bc. Tomáš Jablonický

(2 hodnocení)

1. 6. 2012 21:35:05

Jedná se o dvojci primárních klíčů, primární klíč nemusí mít AI to je fičura v MYSQL.

1. 6. 2012 21:35:05

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770791

(20 hodnocení)

1. 6. 2012 21:36:37

k AI - to vim taky, ale delat si identifikatory rucne je zbytecnost, nicmene samozrejme mas pravdu...

tvuj navrh vypada byt v poradku, co ti tedy neni jasne, pripadne uvazujes nad nejakou jinou variantou o ktere si myslis ze bude treba rychlejsi nebo lepsi?

edit// rozdil mezi primarnim klicem a obycejnym indexem (sekundarnim klicem) je v tomto pripade prakticky minimalni, nicmene uvazuj tak, ze budes hledat v tabulce podle ID knihy... nikoliv podle id knihy+id autora ve spojeni, je tedy lepsi mit na kazdem sloupci vlastni index... tot tedy ma uvaha, muze to nekdo potvrdit ci vyvratit?

1. 6. 2012 21:36:37

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770790

Bc. Tomáš Jablonický

(2 hodnocení)

1. 6. 2012 21:41:11

k čemu ta dvojce primárních klíčá v tabulce kniha slouží, popisuje to vztah kdy kniha bez autora nemohla být napsána ale jak to využiji v praxi? Co se stane když se smaže autor - měla vypadnout chyba ale nic se nestane, lze nastavit do autor_id i null a stale to je dvojce primárních klíčů a porušuje to tu definici kdy potomek musí mít vždy rodiče jinak neexistuje. Jakou tohle má výhodu v případě select * from kniha where autor_id=1 ... je to vyhledání rychlejší než když se jedná o sekundární klíč jak se dotazovat? mám v tom guláš :-)

1. 6. 2012 21:41:11

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770789

(20 hodnocení)

1. 6. 2012 21:44:02

osobne bych tim zbytecne nezatezoval hlavu a pouzival hlavne spravne foreign key, ktery zajisti ze pokud zmizi autor, zmizi i kniha + nastaveni ze sloupec neni (tedy nesmi byt) null :) tim vztahy popises spravne a bude to podle me ve velkem mnozstvi rychlejsi nez primarni klic nad dvema sloupci...

1. 6. 2012 21:44:02

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770788

Jirka

(74 hodnocení)

1. 6. 2012 21:46:33

Taky na tom nevidím nic nenormálního.

každá tabulka má svůj primary key a ten foreign fk_kniha_autor se indexuje hlavne kvuli joinum a podobnym operacim, aby se nemuselo prochazet v tabulce

co se tyce mazani klicu v dalsich tabulkach pri techto vztazich - nastudujte si SQL, to jsou zakladni veci :)

1. 6. 2012 21:46:33

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770787

(20 hodnocení)

1. 6. 2012 21:47:42

primarni klic nad dvema sloupci se pouziva u M:N u spojovaci tabulky... ale u 1:N bych ho asi vazne nepouzil, nemuzu porad zjistit proc...

1. 6. 2012 21:47:42

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770786

Jirka

(74 hodnocení)

1. 6. 2012 21:51:03

mozna by cely rozdil vysvetilo, jak jste to delal doted, tak jak je to na obrazku je to spravne

Napsal Aleš Jiříček;802886
primarni klic nad dvema sloupci se pouziva u M:N u spojovaci tabulky... ale u 1:N bych ho asi vazne nepouzil, nemuzu porad zjistit proc...

PK a FK se indexuji stejne prece (kdyz to bude stejny typ), rozdil byva jen v nastaveni autoincrementu

1. 6. 2012 21:51:03

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770785

Bc. Tomáš Jablonický

(2 hodnocení)

1. 6. 2012 21:51:11

http://www.youtube.com/watch?v=mVfQtp8Ve9I tady je ten problém nastíněn (moc anglicky neumím)

u vztahu M:N (dekompizice) se toto přímo nabízí ale nevím z jakého důvodu se to používá u vztahu 1:1, 1:N

1. 6. 2012 21:51:11

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770784

(20 hodnocení)

1. 6. 2012 21:55:53

tak jo uz to chapu, tam jde proste o to ze to ma zajistovat ze proste oboje bude vyplnene, ze to bez toho zkratka nelze vytvorit ani, ale rychlost nebo cokoliv jineho to urcite neovlivni a nahradi to i klasicky postup co jsem popisoval nahore, tedy spravne nastavit FK a sloupec nenastavit jako null, takze vlastne dosahnes toho sameho... S primary key to bude asi spravnejsi z hlediska navrhu - lepe to popisuje situaci, nicmene fungovat by to melo uplne stejne. Uprimne jsem to doted nedelal a to jsem uz delal hoden slozite a rozsahle databaze... mozna se nad tim i zamyslim :)

1. 6. 2012 21:55:53

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770783

Jirka

(74 hodnocení)

1. 6. 2012 21:57:50

priklad 1:1

tab auto - tab motor

kazda bude mit PK a auto i FK z motoru

1. 6. 2012 21:57:50

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770782

Bc. Tomáš Jablonický

(2 hodnocení)

1. 6. 2012 22:10:33

Takže teď jsem to oskoušel. autor_id je index a tvoří primary key s id (kniha), fk je no action, když vložím autora a k němu knihy a pak autora smažu vyběhne chyba

#1451 - Cannot delete or update a parent row: a foreign key constraint fails

u sekundárního klíče by se autor smazal a knihy s autor_id fk no action by zustali.

Takže tento vztah vlastně zajistí, že když má rodič potomky nemuhu je smazat aniž bych smazal jejich děti předem tedy on delete cascade.

1. 6. 2012 22:10:33

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770781

(20 hodnocení)

1. 6. 2012 22:39:26

okay diky za presnejsi objasneni rozdilu, obcas se muze hodit

1. 6. 2012 22:39:26

https://webtrh.cz/diskuse/identifying-a-non-identifying-relationships/#reply770780

Pro odpověď se přihlašte.

Přihlásit