Diskuze: Cizí klíč a spojení tabulek

Člen

Zobrazeno 13 zpráv z 13.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
Ahoj, primární klíč jednoznačně identifikuje záznam (řádek) v tabulce. Proto musí platit, že primární klíč musí být unikátní (nesmí se jeho hodnota v dané tabulce opakovat). Cizí klíče jsou hodnoty v tabulce, pomocí kterých se odkazujeme na konkrétní záznamy (řádky) většinou v jiné tabulce. Pokud chci takto záznamy mezi sebou propojit, musí platit, že hodnota i datový typ obou klíčů jsou v obou tabulkách shodné.
Zkusil jsem si na nečisto na dvou testovacích tabulkách a fungovalo to. Pak jsem to předělal na ty tabulky, které opravdu potřebuji a nejsem schopen to rozchodit.
Pr. 1, co psal Josef
autor: id_autor, data -- id autor je cislo radku tabulky (kdyz potrebujes smazat radek, najdes ho podle tohoto id)
kniha: id_kniha, id_autor, data -- id_kniha je cislo radku tabulky; id_autor je klic z jine tabulky
(v tomto priklade predpokladam, ze ma kniha jenoho autora)
1. Takze, pokud mas id jako cislo radku, je to hlavni klic, typu PRIMARY.
Cislo radku musi byt jedinecne UNIQUE. A to se zarucuje pres AUTOINCREMENT, kdy
pri INSERTUu si samo sql urci hodnotu, kterou tam ulozi a soucasne si pro dalsi
insert v nejake tajne promenne zvysi cislo radku. Takze v dalsim insertu opet
vklada unikatni.
Samozrejme, je mozne vlozit radky i s vlastnim id_radku. Treba pri kopirovani
shopu z jednoho webu na druhy. Jen ti pak sql pinda, kdyz se cislo radku opakuje
a dane radky vynecha nebo cely prikaz zastavi.
2. V tabulce knihy je id_autor jako klic, ktery slouzi pro propojeni s tabulkou autor. nemusi byt unikatni, neni tam jako autoincrement a neni ani primarni. Je to proste obecne cislo. (muj priklad). Cili, kdezto v prvni tabulce zadavas vschny 3 veci do struktury tabulky, u druhe nesmis. Druha ma svuj primary (autoincrement unique) key a tim je id_kniha.
Pr. 2
autor: id_autor, data
kniha: id_kniha, data
autor_kniha: id, id_autor, id_kniha
tabulka autor obsahuje seznam autoru
tabulka kniha obsahuje seznam knih
tabulka autor_kniha propojuje autory na knihy
Pozn: U autor_kniha: id jsem nedaval popisek (jenom jsem to nazval id), protoze ho nepotrebuji pro zadnou dalsi tabulku. Ale spousta lidi pouziva id_autor_kniha. Alu pro autora a knihu popisky mam, protoze je potrebuji odlisit v jinych tabulkach. A kdyz budu delat LEFT JOIN ON tab1.id_autor=tab2.id_autor, tak mam v obou tabulkach stejne nazvy pro stejne sloupce.
Mysleno tak
autor: 1, Tomas
autor: 2, Petr
kniha: 1, Harry Potter
autor_kniha: id, id_autor, id_kniha
autor_kniha: 1, 1, 1
autor_kniha: 2, 2, 1 - cili, id_kniha nemuze byt unique, protoze ve dvou radcich
(radek id=1 a radek id=2) ma tu samou hodnotu (1 a 1)
A mimochodem, poradi sloupcu by spis melo byt v te tabulce id, id_kniha, id_autor
A id_autor unique v jedne tabulce propojeni take nemuze byt unique, protoze
vice knih mohl napsat jeden autor.
Ale v tech hlavnich tabulkach, tam je to cislo radku.
Nevim, zda to ted bude srozumitelnejsi, ja moc vysvetlovat neumim
Jo, kazda tabulka ma vlastni definici klicu. Mozna delas tu chybu, ze kdyz v
jedne tabulce das primary, tak v te druhe se snazis dat klici s podobnym nazvem
take primary. Takze u tabulky autor_kniha se snazis vsem klicum dat primary. Coz
je nesmysl. Cislo radku, unikatni, je tam jenom sloupec id, tam prvni. Ty
ostatni jsou uz obecna data.
autor_kniha: id, id_kniha, id_autor -- nebo zjednodusene zapsano:
autor_kniha: id, data
Moc děkuji za podrobné vysvětlení Jde o to, že když poskládáš dotaz na úrovni klasického PHP s
MySQL pomocí INNER JOIN nebo LEFT JOIN, tak to funguje, jelikož to ani
žádné cizí klíče nechce. Horší je to v tom Nette, že tam se to už bez
těch klíčů neobejde.
$test = $this->database->getChatRooms()->joinWhere('chat_permissions', 'id = chat_id');
foreach($test as $t)
{
bdump($t['name']);
}
ALTER TABLE `chat_permissions`
ADD CONSTRAINT `chat_permissions_ibfk_1` FOREIGN KEY (`chat_id`) REFERENCES `chat_rooms` (`id`);
Pozn. první img je chat_permissions a druhý chat_rooms
Error: No reference found for $chat_rooms->chat_permissions.
Pročítal sis manuál k tomu?
Zde je to celkem srozumitelně popsané:
https://doc.nette.org/…ase-explorer#…
Ahoj. Nebylo by pro tebe řešením využít rozšíření dibi? Zde je
dokumentace.
V tomto případě můžeš psát klasické sql dotazy jak se ti zlíbí.
Zobrazeno 13 zpráv z 13.