devel.cz

Komentáře

• kacerr : Takze napriklad box do pohlavi mi nikdo dat nemuze, protoze tabulka ktera obsahuje pohlavi tam ma hodnotu ktera by mela odpovidat jednomu ze zaznamu z tabulky "ciselnik" kde id_atribut = id_atributu_pohlavi — 17.3.2014
• Taco : A kde vezmeš ten id_atributu_pohlaví? — 17.3.2014
• kacerr : ten znam zrovna tak jako bych znal nazev tabulky, kdyby to bylo treba ciselnik_pohlavi, trosku mne mrzi, ze misto toho aby se resily nejaky veci, tak se furt nekde hleda nejakej problem, kterej ani v puvodnim dotazu neni — 17.3.2014
• Taco : No, to byl pouze přátelský pokus tě navést na "pravou cestu", proč bych tvé řešení nepoužil. Ale když ti to tak vadí, nebudu pokračovat. Pokud máš takovou touhu cpát různá data do jednoho zdroje, tak by jsi měl opustit relační databázi, a zkusit nějaké NoSQL. Tam je to právě naopak: nejdříve se tam nalejou data, a pak se řeší, co a jak z toho lze vytáhnout. (Samozřejmě zjednodušuji.) — 17.3.2014
• kacerr : Ja jsem odchovanej relacnima databazema, nad NoSQL storama jsem premejslel ale zatim se na vyvoj divam takovym zpusobem, ze jsem pro ne vyuziti nenasel. Krome toho, kdyz chces k nejakymu zaznamu ulozit nejaky dopredu neznamy informace. Ktery zatim v pripadech co jsem zazil nebyly relevantni z pohledu hledani/trideni, takze jsem je flakl jako json do jednoho sloupce (ted by se na to asi hodil postgres hstore, pac ten s tim i nejaky operace umi). Ale jak jsem rikal, kvuli 10ti stejnym ciselnikum se mi nechce delat 10 tabulek ale misto toho jednu, do ktery je vsechny "zkondenzuju". Sam nevim jestli je to dobre nebo spatne, takze se na to ptam. A jedina zatim relevantni vec ktera rika proc to nedelat se mi zda to, ze nemuzes pouzit referencni integritu na urovni databaze, alespon ne nejakym beznym trivialnim zpusobem .... jenze ... tim ze vetsinou klient mych databazi je jen jedna aplikace tak to asi neni tak nezbytne nutny a uprimne jsem v podstate cizi klice nikdy nepouzil a nikdy mi nechybely. Respektive pouzil v db schematu a z pohledu aplikace jsem se s nima setkal snad jedine v pripade kdyz mi delaly problemy pri importu dat. — 17.3.2014
• Taco : Nezlob se na mne, ale prohlásit v jednom příspěvku "jsem odchovanej relacnima databazema" a zároveň "jsem v podstate cizi klice nikdy nepouzil a nikdy mi nechybely"... Pokud hledáš argument, tak to můžeš brát i takto. Způsob 1, protože není žádný důvod, proč to tak nepoužít. Argument, že se ti nechce dělat více tabulek je nevalidní. Mě se nechce věcí. — 17.3.2014
• kacerr : Tady to asi budu muset rozjet trochu na Kita ;-). To ze jsem odchovanej relacnima databazema jsem myslel zejmena v souvislosti s tema NoSQL, se kterejma nemam praktickou zkusenost zadnou. Nejsem databazeovej master, ale zaroven mam docela dobrou predstavu jak to uvnitr funguje, takze uplne mimo taky nejsem. Nedelal jsem s obrovskejma databazema, ale delal jsem s databazema, ktery mely par desitek tabulek a nejaky desitky/stovky tisic zaznamu. A mozna je to divny, ale k cemu cizi klice POTREBUJES? je mi jasny, ze pokud jsou spravne vytvoreny, tak ti neumozni vytvorit zaznamy kdy neco bude "ukazovat" na neco co neexistuje a umozni ti napriklad kaskadove mazat. Takze kdyz je tam mit nebudes, tak tyhle veci budes muset osetrit jinak (a nebo ti to bude tak trochu jedno a pokud nekdo, protoze z normalniho pouziti aplikace tam nic takovyho nevznikne a pokud se v ty databazi bude nekdo hrabat nejak jinak, tak by asi mel vedet dost dobre co dela). A nejde o to jestli se mi chce nebo nechce delat 1 nebo 10 tabulek. Proste uvazuju nad tim, co mi 1 tabulka oproti 10ti da nebo ubere? Ve finale to zadny drama neni a vim naprosto jiste, ze fungovat bude jak jedno tak druhy. Jen mne zajimaly nejaky uvahy a argumentace. Nevim jestli taky trpim nejakym problemem a nemuzu pochopit jasny veci, ale proste mi to pripada, ze jsem tu zatim na zadny poradny argumenty nenarazil. — 17.3.2014
• Taco : "k cemu cizi klice POTREBUJES?" - připodobnil bych to k slabě versus silně typovaným jazykům. Obé má své. Ale proč u silně typovaných jazycích ty typy nepoužívat? A pokud tě to obtěžuje, nebo tě to nebaví, tak používej jiný jazyk. # Cizí klíče slouží k tomu, aby jsi měl v databázi pořádek. Pokud je nepoužíváš, tak nikdy nemůžeš mít jistotu správnosti dat. A ne, validace na vyšší vrstvě je hloupost. Proč to dělat jinde, než tam, kde to má být? # "co mi 1 tabulka oproti 10ti da nebo ubere" - už to tu zaznělo. Zvýší ti složitost validace, kterou musíš dělat. Budeš mět křehčí model, protože si dobrovolně zavádíš do systému možnost chyby. Z mého hlediska ti to nepřinese žádný užitek. Jen práci navíc. — 18.3.2014
• Pavel Hodek : Kromě integrity dat mě ještě v souvislosti s cizími klíči napadá, lepší podpora psaní dotazů v různých IDE; generování ORM; kaskádové update či delete; efektivnější dotazování/zamykání záznamů pokud mám ke každému klíči založený index. Cizí klíče jsou nutnost, bez nich radši o databázi ani nepřemýšlejte. Databáze bez nich je jen halda sólo tabulek bez vztahů - jakmile s tím bordelem bude muset pracovat i někdo jiný, tak vás prokleje, to si buďte jist. — 18.3.2014
• kacerr : Lepsi podpora dotazu v IDE je vec, kterou jsem nikdy nepouzil a nevim jestli je to potreba, proste to napisu "z hlavy", ORM jsem pouzil parkrat a bez cizich klicu se obeslo, to jestli je/neni index na sloupci je asi naprosto nezavisle na tom jestli to je/neni cizi klic. Takze zbyva to kaskadove delete/update. Uznavam, ze existence cizich klicu dela ten databazovej model citelnejsi, pokud jsou zachovany nejaky rozumny jmenny konvence, tak verim tomu ze kdyz s tim pak pracuje nekdo jinej, tak mu to pujde docela dobre i bez cizich klicu. Ja netvrdim, ze nemit cizi klice je lepsi nez je mit, ale zaroven tvrdim, ze moje prakticka zkusenost mi rika, ze kdyz tam nejsou tak to zasadni negatvini vliv asi nema. — 18.3.2014
• Taco : "zasadni negatvini vliv asi nema" - Co si chudák programátor má počít, když mu předáš takovéhle schema. Má dát výpověď? A bude to dělat násobně déle (s přihlédnutím k množství chyb, které jsi mu zajistil). — 18.3.2014
• kacerr : Jakych chyb? Data jsou konzistentni, je zrejme jake jsou relace mezi tabulkami, mozna je i schema s vazbai namalovane. Asi moc dobre nepujde s tim schematem pracovat s nejakejma nastrojema, ktery si nactou strukturu databaze a pomoci tech klicu treba generujou ORM jak tu nekdo zminil. Muzes bejt konkretni? Naprosto vazne. Opakuju, netvrdim v zadnym pripade, ze je lepsi cizi klice nemit nez mit (sam se klonim spis k tomu, ze ty cizi klice rozhodne zbytecny nejsou), ale fakt by mne zajimalo jaky konkretni problemy prinasi je nemit. — 18.3.2014
• podhy : "Data jsou konzistentni" data jsou konzistentní do té doby než vám programátor udělá v aplikaci chybu (mám zde zrovna jednu takovou hodně zábavnou open source aplikaci pod rukama) nebo někdo upraví data přímo a ne přes tu vaší aplikaci. Cascade update/delete je spíš taková příjemná "fíčura" navíc. Hlavní je, že se můžete na data spolehnout. Co se týče indexů některé databáze je prý generují automaticky. — 18.3.2014
• Taco : @kacerr: Tak teď nevím. Jednou píšeš, že: "k cemu cizi klice POTREBUJES?", a pak píšeš: "cizi klice rozhodne zbytecny nejsou". # {"Beckham", [muž, žena, fotbalista, zpěvák, modelka]} - to ti nepřijde jako problém? Musíš programátora učit svůj způsob validace, což mu nezávidím. Zvláště když z praxe mám zkušenost, že to končí slovy: "kašli na to, nemáme čas" # Pokud nemáš ve schematu cizí klíče, a další constrainty, tak data jsou pravděpodobně konzistentní. Někomu to stačí. # Napsat validaci před databází (třeba v php) je rozhodně pracnější, pomalejší, méně spolehlivé. Některé typy validace tím samozřejmě jinak neuděláš. — 19.3.2014
• kacerr : No, tak ted tu trochu mischas dohromady cizi klice a databazovou strukturu (jestli je vazba mezi tabulkami 1:1, 1:n nebo m:n), pokud mam u osoby jedno pole "id_pohlavi" ktery je rekneme int, tak do nej hodontu muz a zena zaroven asi nedostanu (pokud v "ciselniku" muz a zena nejsou jedna hodnota). Duvod proc jsem premyslel nad tim sloucit ciselniky do "super ciselniku" byl ten, ze budu mit nekolik ciselniku s velice malo hodnotama (takze by se na to skoro hodil enum), ale nektery z tech hodnot budou jednou za cas pribyvat (z uzivatelskyho rozhrani - takze na to by se mi enum nehodil). A jeste k tomu jak jsem cizi klice nepotreboval (zrovna totiz delam neco kde asi radeji cizi klice pouzivat budu, protoze jinak aplikace smrdi tim, ze umozni delat nektery veci ktery by se delat nemely - jako treba smazat zaznam, na kterem zavisi hromada dalsich). Duvod proc jsem cizi klice nepotreboval byl zrejme ten, ze v te aplikaci data vzdy pribyvala. Operace "delete" v uzivatelskym rozhrani nebyla pristupna vubec nikde, takze to fungovalo na principu insert + update. Nekonzistentni data z aplikace udelat nesla (protoze nic co vedlo do jine tabulky nebyl text user input, ale nejaky kombo, nebo ta hodnota nebyla uzivatelem editovatelna). — 22.3.2014
• Taco : @kacerr: "No, tak ted tu trochu mischas dohromady cizi klice a databazovou strukturu" - přečti si ještě jednou mé příspěvky. # "Nekonzistentni data z aplikace udelat nesla" - zlatý voči. — 22.3.2014
• kacerr : Precti si prosim svoje prispevky sam. Snazis se naznacit ze nejakemu zaznamu v tabulce rekneme osoba priradim zaroven hodnoty z ciselniku ktere budou muz a zena, tak na to rikam, ze pokud vazba mezi temi tabulkami je atribut v tabulce osoba typu integer, tak to proste nejde (nezavisle na tom jestli tam je nebo neni cizi klic), pokud chci mit moznost mit vice vlastnosti nejakeho druhu (hraje zaroven fotbal, hokej a box) pak databaze vypada zcela jinak (je to skrz vazebnou tabulku - ve ktere jako koneckoncu asi i kdekoliv jinde mi cizi klic zajisti pouze to, ze nepriradim do te hlavni tabulky osoba nejakou neexistujici hodnotu + mi cizi klic pomuze v tom, ze kdyz uz nektere osoby budou fotbalista, tak nebudu moci smazat z ciselniku radek fotbalista). Kdyz rikam, ze nekonzistentni data z aplikace udelat nesla - tim myslim ze ta data nesla udelat pomoci user interface ktery ta aplikace poskytovala. Pokud mi chces neco skutecne vysvetlit, tak si o tom milerad popovidam treba na hangouts: kacerr.cz(at)gmail.com — 23.3.2014
• Taco : @kacerr: Z mého příspěvku: "Pokud by jsi měl naopak každou kategorii dat v jedné tabulce, spousta validace ti odpadne už ze začátku. muž | žena dáš vazbu 1:1, věkovou kategorii pravděpodobně také, a zbude ti kontrola, zda někdo může boxovat a zároveň dělat trojboj." Očekával jsem, že si domyslíš, že u pohlaví bude jeden sloupec s vazbou 1:1, u katergorie bude druhej sloupec s vazbou 1:1, a třetí hodnota bude vytvořena vazební tabulkou. Taky jsem očekával, že důsledky si domyslíš. Ale očekávat ode mne vysvětlování základů, to jsme asi na špatném místě a ve špatném vztahu (nejsem tvůj učitel). — 23.3.2014
• kacerr : Takze se mi tedy jen snazis vysvetlit, to co v tomhle threadu je jasny hned na zacatku a od zacatku jsem si toho vedomej. A sice ze kdyz ty ciselniky dam do jednoho "supr" ciselniku, tak nemuzu pouzit cizi klice k zajisteni konzistentnich dat na urovni databaze. Nad tim nema cena flamovat, mas pravdu, ja s tebou souhlasim a vubec se o to nepru. Psal jsem to asi nekde jinde, uvedomil jsem si, ze cizi klice jsem nepotreboval ve chvili, kdy bylo temer jisty, ze se z toho "ciselniku" nikdy nebude mazat. Pokud mazani z ciselniku hrozi, tak uz pokud by se to resilo na urovni aplikace bude treba hlidat na dost mistech a pak opet souhlasim s tim co se mi snazis rict (pokud to je neco ve smyslu ze pak na to proste nekdo zapomene, neuhlida ... ono by se to pak nejak opravilo, ale to sr..i s tim vypada, ze je fakt zbytecny a je vhodny hlidat to uz na urivni databaze - a jen osetrit failnuty inserty/updaty/delety) — 23.3.2014
• Taco : Až na tu iluzi, že FK potřebuješ jen pro mazání to vypadá, že snad chápeš. — 23.3.2014
• kacerr : muzes bejt trochu konkretnejsi, co je na moji "iluzi" tak iluzorniho? (podotykam, ze to zjednoduseni pouze na DELETE jsi udelal ty) myslim, ze mam docela dobrou predstavu, k cemu se mi cizi klice muzou hodit, ale zaroven jak jsem jiz psal jsem se vetsinou bez nich obesel, takze jestli mi skutecne neco unika a nejsem si toho vedom, rad se necham poucit. — 24.3.2014
• Kit : Kromě popisu schématu jsou FK potřebné téměř při každé operaci s databází. Jak chceš bez FK udělat INSERT? — 24.3.2014
• Taco : @kacerr: Podotýkáš špatně. ■ Restrikce (mezi které FK patří) slouží k zaručení konzistence dat. Tudíž, když budeš chtít do db uložit nějakou hodnotu, db si zkontroluje, zda to smíš. Když budeš chtít změnit nějakou hodnotu, tak si db zkontroluje, zda to smíš. Když budeš chtít smazat, tak si zkontroluje, zda to smíš. Zkontroluje si, zda když něco měníš (kteroukoliv z těch tří operací), tak zda to jde, a případně co by měl udělat, aby to šlo (viz triggery). Možná víš, že kaskádové akce jsou jen formalizovaná forma triggerů. ■ Cizí klíče by se dali zařadit do typového omezení, na stejné úrovni jako typ datetime (schema je graf). Jistě, datum můžeš uložit i jako string, ale předpokládám, že to neděláš, a víš proč to neděláš. A úplně stejně je to s FK. ■ Takže shrnuto a podtrženo cílem všech těchhle tanečků, v podobě datovejch typů, konstraintů, triggerů a podobnejch věcí je jen a pouze snaha mět správná data. ■ To, že si veškerou tu validaci můžeš vytvořit sám, na straně klienta, pomocí nějakých neprůstřelných selectboxů je sice pravda, ale za 1/ databáze ti narozdíl od klienta zaručuje, že ty data budou opravdu správná, 2/ proč to dělat složitě, když to jde udělat normálně. ■ Věřím, že je ti většina toho, ideálně všechno zcela jasné. Ale vzhledem k obsahu tvé argumentace mi přišlo vhodné to shrnout. — 25.3.2014
• kacerr : Shrnul jsi to hezky, ale jestli to jakym zpusobem ja tady argumentuje je v rozporu s tim co se mi snazis vysvetlit, tak pak mam zrejme problem s vyjadrovacima schopnostma. Nicmene jak je implementovany kaskadovy mazani jsem nikdy neresil, ale asi neni spatny si to nechat popsat a eventuelne si o tom neco dohledat, takze pokud to nedonuti mne abych se podival, treba to bude dobry pro nekoho jinyho, takze dik. — 25.3.2014
• kacerr : @Kit To co tu pises o tech inzertech je nejakej trolling, projev tvoji blbosti, nebo snad moji blbosti? Muzu ti rict, ze insertu bez FK jsem ve svem zivote udelal tisice a taky ve vetsine pripadu jsem s tim nemel zadny problem (protoze konzistence dat se da zaridit i jinak - s mensi eleganci a moznou vyssi nachylnosti k chybam, ale to uz je tu myslim vyreseny dost poctive) — 25.3.2014
• Kit : @kacerr: Jak jinak chceš při INSERTu zkontrolovat, zda vkládaný odkaz (id) na jinou tabulku je platný? Že někdo nevkládá odkaz na čtyřicátou položku ze sedmi? Ještě jinak: Když vkládáš záznam do vazební tabulky M:N, tak si tabulka musí nějak ověřit, že oba odkazy na další tabulky existují. — 25.3.2014
• kacerr : Ano, a kdyby ses tady docetl, tak minimalne ja a Taco jsme nezavisle na sobe zminovali minimalne dve moznosti. Ano jeden zpusob (a je docela dobre mozny ze ten nejlepsi) je pouziti ciziho klice. A ten druhej je tak trochu "selskej" nicmene to nic nemeni na tom ze ve spouste scenaru bude taky naprosto bez problemu fungovat. A sice ze si ty "mozny spravny hodnoty zjistis" predem. Pak je tu dalsi mozna situace o ktery ty zrejme momentalne nemluvis, ale z tvoji prvni reakce to jaksi nevyplyva (takze skutecne to budes asi ty kdo by se mel zamyslet nad svejma vyjadrovacima schopnostma) a to je insert do tabulky, ktera zadnou referenci nema, takze tam ani FK byt nemuze. No a pak je tady napriklad jeste varianta ze to ve chvili insertu neresis a aplikace vi jak ma nalozit s informaci ke ktery nenajde spravnou hodnotu v odkazovany tabulce. — 26.3.2014
• dzejkob : Sice mi to přijde dost zbytečná diskuse - ale pro ucelenost - tak "nesprávná hodnota reference" je null i při zachování fk pokud je sloupec nullable což je zase nějaký constraint. — 26.3.2014
• Pavel Hodek : @kacerr: "selskej"? Selský ~ zdravý ~ evidentně pravdivý ~ přirozený, prosil bych abys nedělal ze "selský" synonymum pro "idiotský". Prostě cizí klíče používej a netrap se tím, proč je to správné. Tím bych zcela nesmyslnou diskusi asi uzavřel. — 26.3.2014
• kacerr : No a nebo selskej taky muze znamenat ze na to proste nejdes vedecky, moc v tom nebadas, a udelas to tak jak te to zivot naucil. A moc dobre vis, ze v urcitym rozsahu to bude fungovat presne tak jak potrenujes a nebudes s tim mit zadnej problem. O tom jestli to tak je nejlepsi nema cenu diskutovat, protoze zjevne neni, ale za urcitych okolnosti ti to muze praci i usnadnit a pokud mas dobrou predstavu o tom co delas a proc, tak ani na ty problemy nedojde. Dost by mne zajimalo co konkretne ti pripadne jako "idiotsky" ? Ta puvodni myslenka? Nepouzivani cizich klicu? Nebo snad premysleni nad tim neco udelat jinak nez ty? (ted se do toho poustim trochu po kitovsku, ale musim rict ze argumentace typu .... vlastne zadna argumentace, proste jen stanovisko jak je to "spravne" ... jo, to je to co mne rozciluje, kdyz tu nekdo razi jediny spravny reseni, protoze ono to proste neni cerny nebo bily (vetsinou) — 27.3.2014
• Anonym : "@kacerr A ten druhej je tak trochu "selskej" nicmene to nic nemeni na tom ze ve spouste scenaru bude taky naprosto bez problemu fungovat. A sice ze si ty "mozny spravny hodnoty zjistis" predem." ■ NE a NE a NE Pokud to neuděláš teda v transakci. Protože jinak Dirty Read a Phantom read, pokud bys nezamknul ty řádky, pro které budeš dělat ověření. A navíc tu budou ověřovací SELECTy zbytečně navíc. — 27.3.2014
• kacerr : Nerozumim tomu, proc si vsichni mysli, ze to co se tu resi je nejak strasne komplikovany, ono to tady ma tendence vyznamne odbocovat od puvodni otazky. Ja tady celou dobu resim "maly ciselniky" jejichz obsah se meni jen zridka (neboli uplne bezpecne mohu znat "spravne hodnoty" v aplikaci predtim nez vubec pomyslim na jakykoliv insert/updtate). Dirty Read a Phantom Read zni HUSTE, co to je? ;-) — 27.3.2014
• Anonym : @kacerr: tak použij FK a nedělej flame nad něčím, co je v IT prověřeno cca. 30 lety. Vymýšlíš kolo. Ad Dirty read a vůbec isolace http://en.wikipedia.org/wiki/Isolation_%28database_systems%29 — 27.3.2014
• Kit : @kacerr: Nikdo nenavrhuje superčíselník. Dostal jsi téměř jednoznačnou odpověď: První variantu. — 27.3.2014
• kacerr : Vsak mne ta debata relativne obohatila (sice jsem se mezitim 100x dozvedel spoustu veci co uz davno vim, ale stejne). Skoda, ze jen Pavel Stehule vubec pripustil tu druhou moznost jako variantu (i kdyz aso ne moc dobrou) evidentne podobnou otazku drive jiz resil. Ostatni mne pomerne bezhlave zasypali "best practices" a jak to ma byt VZDY a VSUDE. Ale aspon jsem si ujasnil kdy a proc ten "superciselnik" zas takovy zlo nebude a kdy si klidne lajsnu ho pouzit a kdy bych si tim zivot udelal zbytecne tezkej. — 27.3.2014
• pavel.stehule : @kacerr - super číselník jsem viděl - a všichni tam plakali, že do toho šli. — 27.3.2014
• Pavel Hodek : @pavel.stehule; @kacerr: Taky jeden takovy "superčíselník" máme - je v něm více než 70 číselníků a 12 tisíc řádek. Tohle manažerský rozhodnutí se nám mstí už dobrých 8 let, tak vím o čem mluvím - NIKDY něco takového už nedopustit a případně v rané fázi předělat. — 28.3.2014