Fórum Root.cz
Hlavní témata => Server => Téma založeno: JurijP 16. 05. 2014, 12:21:23
-
Zaujimal by ma nazor ludi, ktori sa venuju databazam. Ci uz ako programatori alebo ako administratori. Ide o porovnanie skolskej teorie s praxou. Vyuzivate v praxi v realnom zivote relacnu algebru pri zostavovani dotazov (prepisujete sql dotaz do relacnej algebry), optimalizacii dotazu? Vypocitavate odhad velikosti dotazu? Chcem len vediet, ci sa v skole opat ucia uplne zbytocnosti, ktore sa v praxi nevyuzivaju.
-
Vyuzivate v praxi v realnom zivote relacnu algebru pri zostavovani dotazov (prepisujete sql dotaz do relacnej algebry), optimalizacii dotazu? Vypocitavate odhad velikosti dotazu?
3x Ne.
Chcem len vediet, ci sa v skole opat ucia uplne zbytocnosti, ktore sa v praxi nevyuzivaju.
Ano.
Návrh dotazu probíhá tak, že se to naplácá tak aby to vracelo co to vracet má a když to běží dlouho, tak se to dá k přezkoumání někomu kdo tomu rozumí, přepíše se to, nasadí se indexy a podobně. Vždy je to silně závislé na implementaci SQL stroje, nikoliv na nějaké teorii.
-
docela trefne popsani reality. ale zase je vyhodny byt tim komu to daji prezkoumat takze teorii urcite znat.
-
Vyuzivate v praxi v realnom zivote relacnu algebru pri zostavovani dotazov (prepisujete sql dotaz do relacnej algebry), optimalizacii dotazu? Vypocitavate odhad velikosti dotazu?
3x Ne.
Chcem len vediet, ci sa v skole opat ucia uplne zbytocnosti, ktore sa v praxi nevyuzivaju.
Ano.
Návrh dotazu probíhá tak, že se to naplácá tak aby to vracelo co to vracet má a když to běží dlouho, tak se to dá k přezkoumání někomu kdo tomu rozumí, přepíše se to, nasadí se indexy a podobně. Vždy je to silně závislé na implementaci SQL stroje, nikoliv na nějaké teorii.
coz nemeni nic na tom, ze normalizace databaze se bezne pouziva, dotazy se optimalizuji a prepisuji
plus samozrejme zalezi na skole
-
takze napr. to co obsahuje tento dokument https://dip.felk.cvut.cz/browse/pdfcache/petrv1_2009dipl.pdf (https://dip.felk.cvut.cz/browse/pdfcache/petrv1_2009dipl.pdf) tu relacnu algebru, optimalizacia, resp. vypocet ceny sa v praxi az tak neuplatnuju?
-
Dotazy do relační algebry nepřepisuji, vše ostatní ale běžně používám.
čím větší výkon chcete od databází, tím důležitější je jim rozumět. A čim víc jim rozumíte, tím lepší pak budete mít pozici, bo pro velkou část IT jsou databáze magie - o které vědí lautr kulové (přičemž to tak také v praxi vypadá).
SQL je jazyk (prostředí) vymyšlené pro laiky - takže se jej může naučit používat každý - něco jiného je ale jej správně (bezchybně) používat. A na to už se teorie hodí.
-
takze napr. to co obsahuje tento dokument https://dip.felk.cvut.cz/browse/pdfcache/petrv1_2009dipl.pdf (https://dip.felk.cvut.cz/browse/pdfcache/petrv1_2009dipl.pdf) tu relacnu algebru, optimalizacia, resp. vypocet ceny sa v praxi az tak neuplatnuju?
Záleží, co děláte - při menších projektech se tyto detaily neřeší - při trochu větších projektech a větší zátěži bez těchto a dalších znalostí můžete mít velké problémy. Praxe má samozřejmě daleko k ideálů - takže ve výsledku velké množství firem má větší nebo menší problémy, bo jim chybí lidi s těmito znalostmi.
-
pro velkou část IT jsou databáze magie - o které vědí lautr kulové (přičemž to tak také v praxi vypadá).
Slova hodne vytesania do mramoru :)
-
takze prax je taka, urobime to tak, ako pozadujeme, veriac, bude to dobre a rychle. optimalizaciu, nejake vypocty cien vykonavania planu sa neriesia.
-
povedal by som ze prax je rovnaka ako ked programujes hocico.. pokial je prvotny napad dostatocne rychly na to aby ti to nevadilo tak sa optimalizaciou nezaoberas :) ale v momente ked je tvoj prvotny napad nechutne pomaly tak zacnes optimalizovat... a na optimalizaciu sa ti veci co sa v skole naucis zidu..
-
Praxe je taková, že uděláš optimalizovaný dotaz s indexy atp. běží to ok. Pak příjde zákazník, že chce další data do výsledku, tak přídáš joiny do dalších 10 tabulek, tři-čtyři subselecty a volání funkce a pak se diví, že to je pomalé :P Na zákazníky bacha!!!
-
Pro skutečný vývoj na databázích považuji znalost relační algebry jako nutný základ. Člověku to dá vhled do toho, na jakých principech to funguje. Z celého studia na MFF UK zrovna tohle užiju nejvíc.
-
cize chces povedat, ze clovek bez znalosti relacnej algebry, pracujuci s databazami, nemoze byt dobry? Urcite su taki a je ich veeeela a bez relacnej algebry zarabaju velke peniaze :)
-
vydelavat velke penize nemusi nutne znamenat, ze tomu clovek rozumi (staci se podivat na nektere manazery ;-) )
MK nikde nepise, ze bez znalosti relacni algebry nemuzes byt dobry, ale urcite tomu budes rozumet vice, kdyz ji budes umet (a propos, chces radu, nebo tu vyvolat flame?)
-
ziaden flame,
-
cize chces povedat, ze clovek bez znalosti relacnej algebry, pracujuci s databazami, nemoze byt dobry? Urcite su taki a je ich veeeela a bez relacnej algebry zarabaju velke peniaze :)
Může mít dobrou mzdu a o teorii nemusíte vědět vůbec nic - ale také příště můžete být nezaměstnaný. Vědomosti vám dávají svobodu si vybírat práci, zaměstnavatele, ... Donedávna, kdo uměl zapnout počítač, tak si v IT našel místo. Jenomže dneska školy chrlí studenty, a z té masy se dají dohledat šikovní s teoretickými znalostmi, kteří na tom budou o dost lépe, než šikovní bez teoretických znalostí nebo než ti nešikovní. Relační databáze jsou dneska (a ještě 20 let budou) základ.
-
pripadne aplikacia je od databazy tak 'daleko' ze cez tie vsetky layery na nu ani nedovidi :-)
-
cize chces povedat, ze clovek bez znalosti relacnej algebry, pracujuci s databazami, nemoze byt dobry? Urcite su taki a je ich veeeela a bez relacnej algebry zarabaju velke peniaze :)
Může mít dobrou mzdu a o teorii nemusíte vědět vůbec nic - ale také příště můžete být nezaměstnaný. Vědomosti vám dávají svobodu si vybírat práci, zaměstnavatele, ... Donedávna, kdo uměl zapnout počítač, tak si v IT našel místo. Jenomže dneska školy chrlí studenty, a z té masy se dají dohledat šikovní s teoretickými znalostmi, kteří na tom budou o dost lépe, než šikovní bez teoretických znalostí nebo než ti nešikovní. Relační databáze jsou dneska (a ještě 20 let budou) základ.
firma cloveka s teoretickymi znalostami nepotrebuje, ktory vie carovat s relacnou algebrou a jedine kde videl databazu, tak to bolo zo slajdov v skole. Firma potrebuje cloveka s praxou, ma prakticke znalosti, nie teoreticke znalosti. To mi pripomina, ze ked niekto ovlada teoreticku informatiku, tak je to nepostradatelny clovek.
Pochybujem, ze clovek, ktory pracuje niekde 10-20 rokov ako DB specialista, o teorii vie velke prt, ze sa musi obavat o to, ze bude nezamestnany.
-
Chcem len vediet, ci sa v skole opat ucia uplne zbytocnosti, ktore sa v praxi nevyuzivaju.
Podla toho, ako to beries / pocitas. V skole sa uci vela - od jednoduchych selectov, cez navrh tabuliek, relacnu algebru az po spravu.
Ja som s SQL robil aj pred vyukou na skole a vsetko naucene v skole naviac boli len zbytocnosti. Takze v tomto zmysle su to zbytocnosti.
Na druhu stranu, ak sa niekto v zivote nestretol s SQL alebo si nenavrhol svoju mini DB, tomu sa toho moze vela hodit.
Pochybujem, ze clovek, ktory pracuje niekde 10-20 rokov ako DB specialista, o teorii vie velke prt, ze sa musi obavat o to, ze bude nezamestnany.
Ked clovek navrhne par tabuliek, tak ho podla mna musi napadnut, ako to robit spravne (dekompozicia atd). Teoria je potom uz len par pomenovani naviac + iny zapis toho, co uz pozna.
-
takze napr. to co obsahuje tento dokument https://dip.felk.cvut.cz/browse/pdfcache/petrv1_2009dipl.pdf (https://dip.felk.cvut.cz/browse/pdfcache/petrv1_2009dipl.pdf) tu relacnu algebru, optimalizacia, resp. vypocet ceny sa v praxi az tak neuplatnuju?
Ne.
V praxi je na prvním místě vždy praktická znalost konkrétního SQL stroje.
-
cize chces povedat, ze clovek bez znalosti relacnej algebry, pracujuci s databazami, nemoze byt dobry? Urcite su taki a je ich veeeela a bez relacnej algebry zarabaju velke peniaze :)
Může mít dobrou mzdu a o teorii nemusíte vědět vůbec nic - ale také příště můžete být nezaměstnaný. Vědomosti vám dávají svobodu si vybírat práci, zaměstnavatele, ... Donedávna, kdo uměl zapnout počítač, tak si v IT našel místo. Jenomže dneska školy chrlí studenty, a z té masy se dají dohledat šikovní s teoretickými znalostmi, kteří na tom budou o dost lépe, než šikovní bez teoretických znalostí nebo než ti nešikovní. Relační databáze jsou dneska (a ještě 20 let budou) základ.
firma cloveka s teoretickymi znalostami nepotrebuje, ktory vie carovat s relacnou algebrou a jedine kde videl databazu, tak to bolo zo slajdov v skole. Firma potrebuje cloveka s praxou, ma prakticke znalosti, nie teoreticke znalosti. To mi pripomina, ze ked niekto ovlada teoreticku informatiku, tak je to nepostradatelny clovek.
Pochybujem, ze clovek, ktory pracuje niekde 10-20 rokov ako DB specialista, o teorii vie velke prt, ze sa musi obavat o to, ze bude nezamestnany.
Pokud někdo pracuje 10-20 roků s databázemi a o teorii ví velké prt, tak to asi moc použitelný člověk nebude. Nehledě na to, že bez teoretických znalostí jeho znalosti budou čisté vúdú a při řešení problémů bude postupovat metodou Cargo efektu. Což může zafungovat, a také nemusí - jak už tak funguje cargo efekt. Samozřejmě, že čistá teorie je nepraktická - ale i v opačném případě bez znalosti (pochopení) teorie se člověk brzo stane klikačem bez pochopení toho, co a proč dělá. Prostě cargo efekt.
-
cize chces povedat, ze clovek bez znalosti relacnej algebry, pracujuci s databazami, nemoze byt dobry? Urcite su taki a je ich veeeela a bez relacnej algebry zarabaju velke peniaze :)
Může mít dobrou mzdu a o teorii nemusíte vědět vůbec nic - ale také příště můžete být nezaměstnaný. Vědomosti vám dávají svobodu si vybírat práci, zaměstnavatele, ... Donedávna, kdo uměl zapnout počítač, tak si v IT našel místo. Jenomže dneska školy chrlí studenty, a z té masy se dají dohledat šikovní s teoretickými znalostmi, kteří na tom budou o dost lépe, než šikovní bez teoretických znalostí nebo než ti nešikovní. Relační databáze jsou dneska (a ještě 20 let budou) základ.
firma cloveka s teoretickymi znalostami nepotrebuje, ktory vie carovat s relacnou algebrou a jedine kde videl databazu, tak to bolo zo slajdov v skole. Firma potrebuje cloveka s praxou, ma prakticke znalosti, nie teoreticke znalosti. To mi pripomina, ze ked niekto ovlada teoreticku informatiku, tak je to nepostradatelny clovek.
Pochybujem, ze clovek, ktory pracuje niekde 10-20 rokov ako DB specialista, o teorii vie velke prt, ze sa musi obavat o to, ze bude nezamestnany.
Je to prostě rozdíl mezi zedníkem a inženýrem. Zedník postaví rodinný domek, ale na most už potřebujete inženýra.
-
Ano, mnoho lidí tvrdí, že to co se naučili ve škole se v praxi tak dělat nedá. Je to asi jejich omluva pro to, aby to mohli nabastlit jak jim to od ruky upadne.
Co se týče optimalizace, dle mé praxe plyne, že je důležité zejména pochopit návrh db, tedy alepoň normální formy. Potom už to db engine zpracuje vyhovujici rychlosti. Když se použijí vhodné datové typy a funkce k nim, je to už skoro dokonalé. Další optimalizace už záleží na situaci.
Co z praxe považuji za horší je to, že v praxi vlastně nikdo neví (konkrétně zadavatel), co se do té DB bude dávat a co získávat. Neexistuje žádný model dat, před samotnou analýzou a všechno se bastlí za běhu. Takže i DB schémata, které na počátku mají hlavu a patu se po x iteracích změní na 40 záznamů typu VARCHAR (255), a to jen proto, že dodavatel dat v průběhu používání programu 80x změnil formát dat (zdravíme státní zprávu).
-
Chcem len vediet, ci sa v skole opat ucia uplne zbytocnosti, ktore sa v praxi nevyuzivaju.
Podla toho, ako to beries / pocitas. V skole sa uci vela - od jednoduchych selectov, cez navrh tabuliek, relacnu algebru az po spravu.
Ja som s SQL robil aj pred vyukou na skole a vsetko naucene v skole naviac boli len zbytocnosti. Takze v tomto zmysle su to zbytocnosti.
Na druhu stranu, ak sa niekto v zivote nestretol s SQL alebo si nenavrhol svoju mini DB, tomu sa toho moze vela hodit.
Pochybujem, ze clovek, ktory pracuje niekde 10-20 rokov ako DB specialista, o teorii vie velke prt, ze sa musi obavat o to, ze bude nezamestnany.
Ked clovek navrhne par tabuliek, tak ho podla mna musi napadnut, ako to robit spravne (dekompozicia atd). Teoria je potom uz len par pomenovani naviac + iny zapis toho, co uz pozna.
ja som sa na byvalej VS ucil, kde primarny kluc oznacovali napr. rodne cislo. Skutocnost je taka, ze za primarny kluc sa nedava nieco ako rodne cislo, ale umelo vytvoreny, nejake ID. Takze teoria je uplne niekde mimo realitu.
A myslim, ze pri navrhu DB si nebudem kreslit nejaku relacnu algebru.
To Pavel:
nemyslim, ze o teorii vie velke prt. urcite musi poznat zakladne veci DB, ale zrejme sa zaobide bez nejakej relacnej algebry, a urcite ho to nebude robit nepouzitelnym. A urcite, ak clovek po X rokoch nepouzivania nejakej relacnej algebry, si tazko spomenie nato, co to vobec je, resp. ako sa to zapisuje.
Ak je zakaznik a zamestnavatel spokojny, som spokojny aj ja, ked pritom este dostanem zaplatene.
-
To Pavel:
nemyslim, ze o teorii vie velke prt. urcite musi poznat zakladne veci DB, ale zrejme sa zaobide bez nejakej relacnej algebry, a urcite ho to nebude robit nepouzitelnym. A urcite, ak clovek po X rokoch nepouzivania nejakej relacnej algebry, si tazko spomenie nato, co to vobec je, resp. ako sa to zapisuje.
Ak je zakaznik a zamestnavatel spokojny, som spokojny aj ja, ked pritom este dostanem zaplatene.
Pro použití SQL nemusíte z hlavy dát všechny definice - to po letech taky po nikom nikdo nechce. Nicméně vědět, co to je relace, kartézský součin, podmnožina kartézského součinu, ... to je jeden ze základů, a pokud někomu tato znalost chybí, tak např. vysvětlení nějakého problému může trvat půl dne místo pár minut. Pokud někdo netuší, co to je prováděcí plán, tak těžko mu budu vysvětlovat nějaký problém s dotazem. Bez základů statistiky se těžko bude hledat chyba v odhadech, ...
Samozřejmě, že můžete fungovat bez těchto znalostí - a můžete být spokojený, a můžete si i vydělávat. Ale, když to vezmu fotbalově, budete hrát přebor, a na 1 ligu se podíváte v televizi.
-
ja som sa na byvalej VS ucil, kde primarny kluc oznacovali napr. rodne cislo. Skutocnost je taka, ze za primarny kluc sa nedava nieco ako rodne cislo, ale umelo vytvoreny, nejake ID. Takze teoria je uplne niekde mimo realitu.
Umely primarny kluc sa dava preto, lebo ostatne "unikatne identifikatory" sa mozu menit, aj ked tak nevyzeraju. Dnes sa da muz preoperovat na zenu, zajtra najdu 2 ludi s rovnakym rovnym cislom, inokedy sa niekto prestahuje do CR a je to. Vdaka tomu mam napriklad ja 2 rodne cisla (ceske a slovenske). A v Cesku ma niekde vedu pod starym slovenskym, lebo mi ho este pridelilo Ceskoslovensko, niekde pod novym ceskym...
V idealnom svete by sa mohlo pouzivat rodne cislo - akurat v praxi to jednoducho nejde.
V jednom programe pouzivam ako primarny kluc vyrobne cislo pristroja - to je z principu dane, ze sa menit nebude a ze je unikatne. Sef rypal, ze je treba dat umely kluc, lebo sa to tak robi - ale kedze sa mozem spolahnut na unikatnost a nemennost, tak som bol proti a zostalo po mojom.
A myslim, ze pri navrhu DB si nebudem kreslit nejaku relacnu algebru.
Relacna algebra, ako sme ju brali my, je len o zapise selectu. A to by poznat mal, aj ked tomu nepovie takym skaredym spojenim ;-).
-
V jednom programe pouzivam ako primarny kluc vyrobne cislo pristroja - to je z principu dane, ze sa menit nebude a ze je unikatne. Sef rypal, ze je treba dat umely kluc, lebo sa to tak robi - ale kedze sa mozem spolahnut na unikatnost a nemennost, tak som bol proti a zostalo po mojom.
PK se za všech okolností používá celé číslo generované místním SQL strojem/clusterem. Opak je projevem nezkušenosti a nevyzrálosti.
Pro použití SQL nemusíte z hlavy dát všechny definice - to po letech taky po nikom nikdo nechce. Nicméně vědět, co to je relace, kartézský součin, podmnožina kartézského součinu, ... to je jeden ze základů, a pokud někomu tato znalost chybí, tak např. vysvětlení nějakého problému může trvat půl dne místo pár minut. Pokud někdo netuší, co to je prováděcí plán, tak těžko mu budu vysvětlovat nějaký problém s dotazem. Bez základů statistiky se těžko bude hledat chyba v odhadech, ...
Na použití cross join nepotřebujete znalost kartézského součinu.
Na prováděcí plán nepotřebujete znalost relační algebry.
-
Co se týče optimalizace, dle mé praxe plyne, že je důležité zejména pochopit návrh db, tedy alepoň normální formy.
Ja myslim, ze normalne formy kazdeho napadnu. Ja som tiez pred vyukou netusil, co to je, ale DB som navrhoval tak, aby sa mi s tym dobre robilo a nic sa nestracalo. A tak som vlastne niektore normalne formy splnal...
Potom už to db engine zpracuje vyhovujici rychlosti.
U mna je skusenost skor opacna - navrhol som tabulky, po naplneni to bolo pomale; tak sa to trochu denormalizovalo (fuj fuj) a tym sa to zrychlilo.
Když se použijí vhodné datové typy a funkce k nim, je to už skoro dokonalé. Další optimalizace už záleží na situaci.
Funkcie sa zase mne aspon u Oracle 11g velmi neosvedcili, ked islo o nieco viac ako obal tabulky za ucelom oddelenia opravneni. Kde funkcie pomahaju?
Hlavne treba pisat query tak, aby DB pochopila, co chcete a ako to chcete. Ak to nepochopi, tak typicky robi na disku nejake sialene JOINy a to je skoro isty zabijak vykonu. Zle su aj full scany, ale na joiny sa to nechyta.
-
Umely primarny kluc sa dava preto, lebo ostatne "unikatne identifikatory" sa mozu menit, aj ked tak nevyzeraju. Dnes sa da muz preoperovat na zenu, zajtra najdu 2 ludi s rovnakym rovnym cislom, inokedy sa niekto prestahuje do CR a je to. Vdaka tomu mam napriklad ja 2 rodne cisla (ceske a slovenske). A v Cesku ma niekde vedu pod starym slovenskym, lebo mi ho este pridelilo Ceskoslovensko, niekde pod novym ceskym...
V idealnom svete by sa mohlo pouzivat rodne cislo - akurat v praxi to jednoducho nejde.
Navíc rodné číslo není (ani v rámci ČR) ani unikátní identifikátor. Protože se dříve při ručním přidělování rodných čísel občas někdo spletl. Ze stejného důvodu jsou vydaná i rodná čísla, která mají chybnou kontrolní číslici.
PK se za všech okolností používá celé číslo generované místním SQL strojem/clusterem. Opak je projevem nezkušenosti a nevyzrálosti.
Ale ve škole vás budou učit pravý opak.
-
V jednom programe pouzivam ako primarny kluc vyrobne cislo pristroja - to je z principu dane, ze sa menit nebude a ze je unikatne. Sef rypal, ze je treba dat umely kluc, lebo sa to tak robi - ale kedze sa mozem spolahnut na unikatnost a nemennost, tak som bol proti a zostalo po mojom.
PK se za všech okolností používá celé číslo generované místním SQL strojem/clusterem. Opak je projevem nezkušenosti a nevyzrálosti.
Cele cislo to bolo - ale preco by malo byt vygenerovane SQL strojom / clusterom?
Opak je projevem nezkušenosti a nevyzrálosti.
Mne sa tiez dostalo, ze "to predsa kazdy vie". Ale uz sa mi nedostalo, preco je to tak.
Podla mna kazdy vie, ze extra data v DB, kvoli ktorym je casto treba dalsi JOIN, to je zlo.
-
Navíc rodné číslo není (ani v rámci ČR) ani unikátní identifikátor.
O tom som pisal (2 ludia rovnake).
Ze stejného důvodu jsou vydaná i rodná čísla, která mají chybnou kontrolní číslici.
O tomto neviem - stretli ste sa s tym niekedy?
Viem, ze najskor boli 6+3 miestne rodne cisla, potom sa preslo na 6+4 delitelne 11. Ale u niektorych ludi sa spravilo zo 6+3 to "novsie", 6+4 iba tak, ze sa im za rodne cislo prilepila nula, bez kontroly na delitelnost 11. Tak to kontrolujem aj v jednom programe a zatial problem nebol.
-
Cele cislo to bolo - ale preco by malo byt vygenerovane SQL strojom / clusterom?
Externí čísla se v praxi vždy po čase pokazí. I když zákazník odpřísáhne na smrt své matky že sériové číslo bude unikátní, stejně za rok začne vyrábět různé komponenty se stejným sériovým číslem.
-
Cele cislo to bolo - ale preco by malo byt vygenerovane SQL strojom / clusterom?
Protože jinak hrozí že nebude unikátní. Nutit více aplikačních serverů aby toto splňovaly je zbytečně složité, navíc co když přidáte další aplikační server který bude používat úplně jiné technologie než ty předchozí?
Mne sa tiez dostalo, ze "to predsa kazdy vie". Ale uz sa mi nedostalo, preco je to tak.
Podle primárního klíče se třídí při provádění dávkových updatů (které vedou k zámkům), tak aby se zajistilo že nebude docházet k deadlockům. Je třeba mít možnost podle něčeho třídit, a primární klíč který je navíc celé číslo je ideální - jednak na něm je index (takže často není třeba třídit, stačí vzít záznamy z indexu a je rovnou setříděno) a jednak údržba takového indexu je pro celá čísla efektivní.
-
Cele cislo to bolo - ale preco by malo byt vygenerovane SQL strojom / clusterom?
Externí čísla se v praxi vždy po čase pokazí. I když zákazník odpřísáhne na smrt své matky že sériové číslo bude unikátní, stejně za rok začne vyrábět různé komponenty se stejným sériovým číslem.
Kedze sa to cele riadi podla seriovych cisel, tak je jednoducho nerealne, ze by to zmenili. Predavanie nejakeho kusu "mudreho" zeleza (v obidvoch smeroch!) v podstate prebieha tak, ze sa skontroluje seriove cislo a podpise sa to. Keby firma zacala vyrabat ine kusy zeleza v cenach radovo milionov korun (alebo este lepsie - v halieroch ;-) ) s rovnakymi cislami, tak by bol z toho taky bordel, ze by bola uprava DB to najmensie...
Protože jinak hrozí že nebude unikátní. Nutit více aplikačních serverů aby toto splňovaly je zbytečně složité, navíc co když přidáte další aplikační server který bude používat úplně jiné technologie než ty předchozí?
Mozete blizsie vysvetlit suvislost medzi unikatnostou (ktora tam je, ako pisem vyssie) a vyberom aplikacneho servera? Aj keby tam unikatnost nebola, tak to podla mna s aplikacnym serverom nic nespravi.
Podle primárního klíče se třídí při provádění dávkových updatů (které vedou k zámkům), tak aby se zajistilo že nebude docházet k deadlockům. Je třeba mít možnost podle něčeho třídit, a primární klíč který je navíc celé číslo je ideální - jednak na něm je index (takže často není třeba třídit, stačí vzít záznamy z indexu a je rovnou setříděno) a jednak údržba takového indexu je pro celá čísla efektivní.
S tymto v podstate suhlasim - ako to ale odporuje mojim tvrdeniam alebo vysvetluje, preco nie cisla "zvonka"?
-
jednoducho nerealne, ze by to zmenili.
:) :) :) Nereálné je výhradně porušení fyzikálních zákonů.
-
Ze stejného důvodu jsou vydaná i rodná čísla, která mají chybnou kontrolní číslici.
O tomto neviem - stretli ste sa s tym niekedy?
Jsou to desítky případů, takže narazit na to není zas tak jednoduché.
Mimochodem, málokdo se také podívá na to, jak je rodné číslo v zákoně doopravdy definované. Takže neví, že pokud by byl v daném dni rodných čísel nedostatek, přičte se k měsíci 20 (tj. u žen dohromady 70), čímž vznikne další řada rodných čísel. Takových rodných čísel jsem viděl jednotky a žádné nebylo ověřené, takže nevím, zda už skutečně bylo někdy někomu takové rodné číslo vydané. Ale pokud ano, byl by takový člověk chudák.
-
Protože jinak hrozí že nebude unikátní. Nutit více aplikačních serverů aby toto splňovaly je zbytečně složité, navíc co když přidáte další aplikační server který bude používat úplně jiné technologie než ty předchozí?
Mozete blizsie vysvetlit suvislost medzi unikatnostou (ktora tam je, ako pisem vyssie) a vyberom aplikacneho servera? Aj keby tam unikatnost nebola, tak to podla mna s aplikacnym serverom nic nespravi.
Obecně - dokud máte jediný aplikační server a v něm jediný proces který ty identifikátory generuje, jde celkem jednoduše zajistit aby ta generovaná čísla byla unikátní. Až přidáte další aplikační server který bude dostatečně kompatibilní, s trochou práce to zase zajistíte. A až přidáte další aplikační server který nebude dostatečně kompatibilní (např. Java vs. C#) tak se to tak zkomplikuje že si budete říkat "proč jsem vlastně ty unikátní identifikátory od začátku nenechal generovat v té sdílené databázi"... Při návrhu databázové struktury je třeba přemýšlet dopředu a ne se spokojit s tím co je dobré zrovna teď pro aktuální situaci!
Navíc už tu padnul argument se kterým souhlasím - databáze musí mít primární klíče jedinečné, a to lze zajistit jen tím že to budou speciální identifikátory jejichž jediným významem bude právě ta jedinečnost. Převzetím jiných dat, jejichž primární význam je jiný a zodpovědnost za ně je mimo databázi (rodná čísla apod.) nikdy nemůžete zaručit na 100% že budou unikátní. Ne, jakákoliv nižší záruka jedinečnosti (např. 99,999%) prostě není u primárních klíčů dost dobrá! Opět je třeba přemýšlet dopředu a vyhnout se tak zásadnímu zásahu jako je výměna primárního klíče v budoucnosti.
-
Obecně - dokud máte jediný aplikační server a v něm jediný proces který ty identifikátory generuje, jde celkem jednoduše zajistit aby ta generovaná čísla byla unikátní. Až přidáte další aplikační server který bude dostatečně kompatibilní, s trochou práce to zase zajistíte. A až přidáte další aplikační server který nebude dostatečně kompatibilní (např. Java vs. C#) tak se to tak zkomplikuje že si budete říkat "proč jsem vlastně ty unikátní identifikátory od začátku nenechal generovat v té sdílené databázi"... Při návrhu databázové struktury je třeba přemýšlet dopředu a ne se spokojit s tím co je dobré zrovna teď pro aktuální situaci!
Jasne, ale ja ich negenerujem - ja ich dostavam. Robit databazovu robotu v aplikacnom serveri je podla mna vzdy zlo.
Ne, jakákoliv nižší záruka jedinečnosti (např. 99,999%) prostě není u primárních klíčů dost dobrá!
100% nie je nic. Ani ze sequence v Oracle vrati jedinecnu hodnotu (nespolahlive pamate + vesmirny sum).
A ked uz raz vsetko zacne fungovat uplne inak*, tak sa bude musiet aj tak dost vyrazne prerobit databaza, ktora je pomerne uzko spojena s tym, ako to funguje. Alebo sa to da jednoducho do inej tabulky.
Keby sme chceli byt vseobecni, tak by sme dopadli ako co som videl na jednom mensom ceskom eshope - jedna tabulka, v nej id (int) a potom stlpce col1 az col45 typu text, ktore si drzali text s nazvom toho, co drzia a potom hodnoty. To je sice extremne prisposobive, ale robit som s tym odmietol.
*tym myslim - vyrobca zacne vyrabat nieco ine pod tym istym cislom, co by sme chceli tiez evidovat
Mimochodem, málokdo se také podívá na to, jak je rodné číslo v zákoně doopravdy definované.
Cital som zakon a pytal som sa uradnicok. Tych 70 a 20 tam mam; rovnako tam mam aj podporu pre rodne cisla cudzincov (den + 50)
-
Obecně - dokud máte jediný aplikační server a v něm jediný proces který ty identifikátory generuje, jde celkem jednoduše zajistit aby ta generovaná čísla byla unikátní. Až přidáte další aplikační server který bude dostatečně kompatibilní, s trochou práce to zase zajistíte. A až přidáte další aplikační server který nebude dostatečně kompatibilní (např. Java vs. C#) tak se to tak zkomplikuje že si budete říkat "proč jsem vlastně ty unikátní identifikátory od začátku nenechal generovat v té sdílené databázi"... Při návrhu databázové struktury je třeba přemýšlet dopředu a ne se spokojit s tím co je dobré zrovna teď pro aktuální situaci!
Jasne, ale ja ich negenerujem - ja ich dostavam. Robit databazovu robotu v aplikacnom serveri je podla mna vzdy zlo.
OK, dostáváte identifikátory abyste je uložil a prováděl pomocí nich integraci s okolními systémy. Ale proč byste ty samé identifikátory zneužíval jako primární klíče v databázi? Přidejte si jako primární klíč vyhrazené číslo a máte vystaráno - cena za uložení extra čísla ke každému záznamu je minimální, bezpečnost databázového návrhu roste. Dokážete například zajistit že nikdy v budoucnu nebude třeba imeplementovat požadavek na změnu již existujícího identifikátoru? Jediný identifikátor jehož neměnnost a jedinečnost můžete garantovat je takový který je pouze váš, interní, a okolí o něm neví!
Ne, jakákoliv nižší záruka jedinečnosti (např. 99,999%) prostě není u primárních klíčů dost dobrá!
100% nie je nic. Ani ze sequence v Oracle vrati jedinecnu hodnotu (nespolahlive pamate + vesmirny sum).
Provozovat databázi na hardware který není dostatečně kvalitní je blbost. Oproti tomu dostatečně kvalitní hardware (hlavní jsou paměti s ECC) je proti tomu imunní - viz např. starší statistiky Google ohledně opravených chyb pomocí ECC v jejich datacentrech.
-
OK, dostáváte identifikátory abyste je uložil a prováděl pomocí nich integraci s okolními systémy. Ale proč byste ty samé identifikátory zneužíval jako primární klíče v databázi? Přidejte si jako primární klíč vyhrazené číslo a máte vystaráno - cena za uložení extra čísla ke každému záznamu je minimální, bezpečnost databázového návrhu roste. Dokážete například zajistit že nikdy v budoucnu nebude třeba imeplementovat požadavek na změnu již existujícího identifikátoru?
Poziadavky su rozne, ale to treba rozumne filtrovat. Napriklad dnes odomna jeden clovek chcel, aby si na pozadie formularov mohol dat nejaku fotku jemu blizkej osoby, ktora by sa mala dat aj menit - a ze mu nevadi, ze cez nu pojde text... Nie vsetko technicky realizovatelne je treba realizovat. A nie vzdy to musi byt tak, ako si to predstavuju uzivatelia.
Ked je momentalne politika - pouzivame jedno cislo, tak to nevidim dovod menit a osetrovat pripady, keby to bolo inak.
Zoberme si, ze by okrem vyrobneho cisla (VC) zaviedli aj umele id (ID). Momentalne sa vsetko robi podla VC a to teda zarucuje, ze ide o jeden fyzicky pristroj. Pri zavedeni UI teda musi byt nejak vynutene 1:1 mapovanie medzi VC a ID.
A preco? Momentalne uzivatel dostane pristroj a novy nezalozi - lebo uz vie, ze mame konkretne ten evidovany. Keby mal moznost zalozit novy s tym istym cislom, tak by to urcite niekto urobil, aj keby to nebolo treba (ako inak vynutit opak, ked sa bojime unikatnosti?). A hned by bolo treba pristroj odlisovat aj inak - a to nie je v ziadnych protokoloch, nie su na to podklady, takze to by sa z toho uctovnicky asi zblaznili.
Ne, jakákoliv nižší záruka jedinečnosti (např. 99,999%) prostě není u primárních klíčů dost dobrá!
100% nie je nic. Ani ze sequence v Oracle vrati jedinecnu hodnotu (nespolahlive pamate + vesmirny sum).
Provozovat databázi na hardware který není dostatečně kvalitní je blbost. Oproti tomu dostatečně kvalitní hardware (hlavní jsou paměti s ECC) je proti tomu imunní - viz např. starší statistiky Google ohledně opravených chyb pomocí ECC v jejich datacentrech.
[/quote]
Ok, tak nemate tych deviatok 5 ale 20 (tip). 100% z principu nedosiahnete, dokedy budete stavat na fyzike. Vo fyzike neexistuje 100% presne meranie - to nam o hlavu otlkali uz na zakladnej skole, ked sme do protokolu napisali l=10cm a nie l=10cm +-1mm.
-
Zaujimal by ma nazor ludi, ktori sa venuju databazam. Ci uz ako programatori alebo ako administratori. Ide o porovnanie skolskej teorie s praxou. Vyuzivate v praxi v realnom zivote relacnu algebru pri zostavovani dotazov (prepisujete sql dotaz do relacnej algebry), optimalizacii dotazu? Vypocitavate odhad velikosti dotazu? Chcem len vediet, ci sa v skole opat ucia uplne zbytocnosti, ktore sa v praxi nevyuzivaju.
Syntax SQL se naučí kdejaký vůl. U opravdu velkých dat už je třeba vědět, jak databáze (konkrétní implementace) funguje, aby byl dotaz vůbec použitelný. A implementátor musí znát mnohem víc než relační algebru. Takže ve zkratce: pro vola jde o zbytečnost, u vyšších vývojových forem o věc užitečnou až nezbytnou.
-
Zaujimal by ma nazor ludi, ktori sa venuju databazam. Ci uz ako programatori alebo ako administratori. Ide o porovnanie skolskej teorie s praxou. Vyuzivate v praxi v realnom zivote relacnu algebru pri zostavovani dotazov (prepisujete sql dotaz do relacnej algebry), optimalizacii dotazu? Vypocitavate odhad velikosti dotazu? Chcem len vediet, ci sa v skole opat ucia uplne zbytocnosti, ktore sa v praxi nevyuzivaju.
Jelikož jsem to mezi odpovědmi nenašel, tak odpovím sám: přepisování sql dotazů do "relační algebry" (asi míněn nějaký formální matematický zápis?) určitě nikdo v běžné praxi nevužívá (přeci vidím co ten dotaz dělá, ne). Odhadování velikosti dotazu se samozřejmě dělá, opět neformálně/intuitivně (ona to není až taková věda).
Naprosto ale nechápu souvislost s tím zda se "opět učí úplné zbytečnosti" - ta relační algebra JE a tedy se efektivně používá. Jistě, je hodně lidí kteří mohou klidně považovat SQL za něco co přinesl Mojžíš z hory společně s desaterem a vystačí si s tím.
-
Překvapuje mě návrh, jednoznačný identifikátor z venku a syntetický uvnitř ze systému...
To jako když se mi sejdou tři auta se stejným VIN, mám je uložit do systému? Co to je za nesmysl?
Známe lidi, klidně tam ty nesmysly narvou. Pak VIN může klidně být primární klíč a naopak je to silně žádoucí.
Přenos nějakého nesmyslného identifikátoru napříč celým heterogenním systémem je prostě nesmysl.
V servisně orientované architektuře to ani není dobře realizovatelné.
Nedivím se, že pak ty IS stojí za starou bačkoru, pokud každý uvažuje takhle...
Nehledě na to, že běžný databáze už jsou fakt trošku zastaralé, je to ta nejprimitivnější část systému.
Neberu psychopaty, který chtějí pomálu v nich spouštět aplikaci (největší problém dneška - obvykle se to celé musí zahodit)
-
Překvapuje mě návrh, jednoznačný identifikátor z venku a syntetický uvnitř ze systému...
To jako když se mi sejdou tři auta se stejným VIN, mám je uložit do systému? Co to je za nesmysl?
Tomu sa vravi "prakticka skusenost". Programator/analytik nie je vseveduci sef firmy aby rozhodoval, ci bude alebo nebude
branit sekretarke natlacit 3x ten isty VIN do aplikacie na vecne veky a nikdy inak.
Ak spravite aplikaciu kde postavite na DB vrstve identifikator ako VIN, tak bude znacne problematike az nemozne vyriesit
problem "ale chceme nejak podchytit 2x ten isty VIN".
Ked mate pocit, ze ste najmudrejsi na svete a viete naisto, ze VIN sa nebude nikdy opakovat, mate na to unique constraint.
Ked po vas za 10 rokov niekto pride a zisti, ze to fakt potrebuje obist, zrusit jeden constraint a doladit aplikaciu nebude az taky problem.
-
Ak spravite aplikaciu kde postavite na DB vrstve identifikator ako VIN, tak bude znacne problematike az nemozne vyriesit
problem "ale chceme nejak podchytit 2x ten isty VIN".
Ak si niekde potrebujem zapamatat viac udajov k jednemu identifikatoru, tak na to spravim extra tabulku, ktorej jeden stlpec bude aj VIN (alebo jednoduche spojenie 1:N). Robit kvoli tomu identifikator neunikatny a zavadzat si extra umely identifikator je podla mna cestou do pekiel.
Ked mate pocit, ze ste najmudrejsi na svete
Nemusim byt najmudrejsi na svete - staci, ze to mam zarucene od vyrobcu, normami, zakonami a celymi procesmi.
a viete naisto, ze VIN sa nebude nikdy opakovat, mate na to unique constraint.
Aha, takze si budem udrzovat extra index, ktory mi zaruci unikatnost a pre kazde spojenie 1:N budem musiet robit join na to, aby som videl alebo mohol pouzit unikatny identifikator. Join bude sice rychly, ale nebude to rychlejsie, ako keby ho nebolo treba robit.
A cele to preto, ze by nahodou vyrobcovi preskocilo, zakony prestali platit a zmenilo sa uplne vsetko. Zrejmejsi pripad overengineeringu je snad uz len overovanie po kazdom riadku kodu, ci este svet neskoncil.
-
Nedivím se, že pak ty IS stojí za starou bačkoru, pokud každý uvažuje takhle...
Nehledě na to, že běžný databáze už jsou fakt trošku zastaralé, je to ta nejprimitivnější část systému.
Neberu psychopaty, který chtějí pomálu v nich spouštět aplikaci (největší problém dneška - obvykle se to celé musí zahodit)
Jsem jedním z těch psychopatů - databáze, kromě SQL ještě dneska umí i procedurální jazyky s podporou SQL. Když to umíte využít, tak můžete napsat jednoduché rychlé aplikace. Ale všechno má svoje limity, a je dost jiné než klasické OOP programování (případně ještě říznuté ORM). V podstatě jsou to dva nekompatibilní přístupy k programování - přičemž každá strana si o té druhé myslí svoje.
-
Ale všechno má svoje limity, a je dost jiné než klasické OOP programování (případně ještě říznuté ORM).
Ono se zas až tak moc objektově neprogramuje, spíš je to programování s objekty. Zvlášť tam, kde se používá ORM - to je klasické procedurální programování, kde máte datové struktury (to jsou ty ORM "objekty", kde se akorát s daty z venku nepracuje přímo, ale pomocí getterů/setterů nebo properties) a vedle toho kód, který se těmi strukturami něco provádí (dnes se mu většinou říká služby).
-
Hlavne treba pisat query tak, aby DB pochopila, co chcete a ako to chcete. Ak to nepochopi, tak typicky robi na disku nejake sialene JOINy a to je skoro isty zabijak vykonu. Zle su aj full scany, ale na joiny sa to nechyta.
Pokud jsou data strukturovaná dle normálních forem, používají se správné datové typy a indexy jsou tam, kde dle prováděcího plánu mají své opodstatnění, tak to nemůže být pomalé. Stejně tak používání funkcí nad datovými typy přímo v db nemůže (by nemělo být) pomalejší než při jejich zpracování v programu (je tam navíc roudtrip mezi serverem a klientem).
-
Externí čísla se v praxi vždy po čase pokazí. I když zákazník odpřísáhne na smrt své matky že sériové číslo bude unikátní, stejně za rok začne vyrábět různé komponenty se stejným sériovým číslem.
Takže místo toho, aby si to zákazník opravil a zabránil by tak větším zmatkům do budoucna, tak se v DB udělá další, jiné, seriové číslo? To osobně nepovažuji za zlepšení.
-
To jako když se mi sejdou tři auta se stejným VIN, mám je uložit do systému? Co to je za nesmysl?
Nedivím se, že pak ty IS stojí za starou bačkoru, pokud každý uvažuje takhle...
+1
-
Tomu sa vravi "prakticka skusenost". Programator/analytik nie je vseveduci sef firmy aby rozhodoval, ci bude alebo nebude
branit sekretarke natlacit 3x ten isty VIN do aplikacie na vecne veky a nikdy inak.
Ano, praktická zkušenost to bohužel je. A na základě této praktické zkušenosti potom vznikají situace, jako že je třeba vymáhána pohledávka pro zcela jiném člověku podobného jména nebo bohužel neunikátního rč a nikdo se nenamáhá to řešit. Do systému to naťukat lze, počítač řekl, že dlužíte, tak plaťte.
Pokud má někdo za úkol napsat systém pro evidenci vodizel, tak VIN je pro měj dostatečně unikátní už z definice na to, aby z něj mohl být i PK. Protože v běžném režimu se nemůže stát, že dvě různá vozidla mají stejný VIN. Pokud se tak stane, nelze nad tím mávnout rukou, naopak se to musí řešit mimořádně. Systém, který umožní zapsat dvě vozidla se stejným VIN jaksi nikoho nenutí to řešit a v praxi to dopadne nejjednodušší možnou cestou, že to tam dotyčný operátor prostě nechá.
-
Ano, praktická zkušenost to bohužel je. A na základě této praktické zkušenosti potom vznikají situace, jako že je třeba vymáhána pohledávka pro zcela jiném člověku podobného jména nebo bohužel neunikátního rč a nikdo se nenamáhá to řešit. Do systému to naťukat lze, počítač řekl, že dlužíte, tak plaťte.
Pokud má někdo za úkol napsat systém pro evidenci vodizel, tak VIN je pro měj dostatečně unikátní už z definice na to, aby z něj mohl být i PK. Protože v běžném režimu se nemůže stát, že dvě různá vozidla mají stejný VIN. Pokud se tak stane, nelze nad tím mávnout rukou, naopak se to musí řešit mimořádně. Systém, který umožní zapsat dvě vozidla se stejným VIN jaksi nikoho nenutí to řešit a v praxi to dopadne nejjednodušší možnou cestou, že to tam dotyčný operátor prostě nechá.
To, že nějaký údaj není v PK, vůbec neznamená, že se nemůže kontrolovat unikátnost takového údaje. Naopak ten váš přístup znamená, že se pohledávka bude vymáhat po někom úplně jiném, nebo že se na tu duplicitu VIN nepřijde. Když systém to duplicitní rodné číslo neumožní zadat, tak holt tu pohledávku obsluha zapíše k tomu druhému člověku se stejným RČ, a třeba si to bude nějakou dobu pamatovat. A pro to auto si vymyslí jiný VIN, a ten do databáze zadá. Protože je to pořád menší otrava, než to auto neevidovat vůbec.
Všimněte si, že to vyžadování unikátnosti tam, kde v reálném světě identifikátor unikátní není a obsluha programu ten identifikátor nemůže nijak ovlivnit, tu chybu nikdy neopraví, naopak to připraví půdu pro vznik dalších chyb.
-
To, že nějaký údaj není v PK, vůbec neznamená, že se nemůže kontrolovat unikátnost takového údaje.
Boha jeho.
Naopak ten váš přístup znamená, že se pohledávka bude vymáhat po někom úplně jiném, nebo že se na tu duplicitu VIN nepřijde. Když systém to duplicitní rodné číslo neumožní zadat, tak holt tu pohledávku obsluha zapíše k tomu druhému člověku se stejným RČ, a třeba si to bude nějakou dobu pamatovat. A pro to auto si vymyslí jiný VIN, a ten do databáze zadá. Protože je to pořád menší otrava, než to auto neevidovat vůbec.
Všimněte si, že to vyžadování unikátnosti tam, kde v reálném světě identifikátor unikátní není a obsluha programu ten identifikátor nemůže nijak ovlivnit, tu chybu nikdy neopraví, naopak to připraví půdu pro vznik dalších chyb.
Tak jednak VIN unikátní má být (s rč je to horší) a to cos popsal se dá aplikovat na jakýkoliv systém. Ano, pokud to někdo bude chtít obejít a zprasit, tak to vždy udělá. Ale jde o to, jak validní jsou ta data v databázi. V systému typu "naťukejte co chcete, stejně se to nekontroluje" vznikne ten bordel okamžitě a ještě se toho bude cíleně zneužívat. V systému, kde jsou přesně definovaná omezení na data už to tak snadné není. Nehledě na možnost auditu (Filipe, kde jste vzal tento VIN?). V systému typu (id BIGSERIAL, notes TEXT null) ani není co kontrolovat.
-
Rodné číslo také má být unikátní. Jak už jsem psal, to, že nějaký identifikátor není primárním klíčem, ještě neznamená, že se unikátnost nemůže kontrolovat (s varováním) nebo vynucovat. Systém může uživatele varovat, že zadává duplicitní VIN, může vyžadovat schválení duplicitního VINu od dalšího uživatele nebo od vedoucího. Dokonce může mít i kontrolu na unikátnost VIN v databázi, ale když se použije umělý primární klíč, pořád je možnost aplikaci jednoduše upravit, až se přijde na to, že v praxi VIN unikátní není. Je mnohem jednoduší zrušit unikátní index a doplnit varování do aplikace, než ve všech odkazujících tabulkách měnit klíč.
-
Rodné číslo také má být unikátní. Jak už jsem psal, to, že nějaký identifikátor není primárním klíčem, ještě neznamená, že se unikátnost nemůže kontrolovat (s varováním) nebo vynucovat. Systém může uživatele varovat, že zadává duplicitní VIN, může vyžadovat schválení duplicitního VINu od dalšího uživatele nebo od vedoucího. Dokonce může mít i kontrolu na unikátnost VIN v databázi, ale když se použije umělý primární klíč, pořád je možnost aplikaci jednoduše upravit, až se přijde na to, že v praxi VIN unikátní není. Je mnohem jednoduší zrušit unikátní index a doplnit varování do aplikace, než ve všech odkazujících tabulkách měnit klíč.
Na tomto se neshodneme. To, že něco, co bylo původně navrženo jako unikátní nakonec tak moc unikátní není a ještě k tomu to nikdo nechce řešit, je podle mě tak velká změna zadání, že to vyžaduje v podstatě nový návrh. Protože ona změna unikátnosti má podstatný vliv na další logiku aplikace.
(Původní komentář byl delší, ale root se rozhodl, že během psaní zapomene moje přihlášení. Skvělý to systém.)
-
To, že něco, co bylo původně navrženo jako unikátní nakonec tak moc unikátní není a ještě k tomu to nikdo nechce řešit
Tady se nebavíme o tom, jak něco bylo navrženo, ale jaký je o tom předpoklad. Někdo předpokládá, že rodná čísla jsou unikátní (v zákoně je napsáno, že totéž rodné číslo nesmí být přiděleno více osobám), ale pak se zjistí, že dříve nějaká duplicitní rodná čísla přidělena byla. A že to nikdo nechce řešit? Má škola nebo zaměstnavatel prohlásit: "Vážený pane, máte duplicitní rodné číslo, náš informační systém ho nedovolí zadat, tak si laskavě nechtě přidělit nové rodné číslo, a pak vás možná vezmeme?" To, že jsou duplicity někde, kde by být neměly, je problém té primární evidence, která ty identifikátory přiděluje. Nikdo jiný to vyřešit nemůže, ostatní se mohou jen přizpůsobit a počítat s tím, že to s tou unikátností není až tak slavné.
je podle mě tak velká změna zadání, že to vyžaduje v podstatě nový návrh. Protože ona změna unikátnosti má podstatný vliv na další logiku aplikace.
Na další logiku aplikace to nemusí mít vůbec žádný vliv. Třeba pokud pro evidenci osob používám umělý primární klíč a rodné číslo používám jenom jako jeden z evidenčních údajů, nemá změna unikátnosti rodného čísla na logiku aplikace žádný vliv. Dříve uživatel vyhledal osobu podle příjmení nebo rodného čísla a podle dalších údajů ověřil, že jde skutečně o tu správnou osobu (případně podle nich vybral tu správnou), nově bude postupovat úplně stejně.
-
V takových případech ale zase není nutné tam ten údaj vůbec mít. To se zase dostáváme do extrému "bude se sbírat a ukládat všechno, co sbírat a ukládat lze". Ve fyzické praxi potom kdejaký vrátný od dvora s kupou hnoje chce vidět občanku a důkladně si zapíše do knihy návštev #OP. To tam příště můžu poslat svoji občanku, ať to vyřídí za mě, o moji osobu evidentně vůbec nejde.
-
V takových případech ale zase není nutné tam ten údaj vůbec mít.
To pak nevím, jak budete v zaměstnání, ve škole nebo na úřadě osoby identifikovat. Rodná čísla, jména a příjmení a adresy trvalého bydliště odstraníte, a jak pak poznáte, komu máte třeba vydat diplom nebo vyplatit důchod?
-
To pak nevím, jak budete v zaměstnání, ve škole nebo na úřadě osoby identifikovat. Rodná čísla, jména a příjmení a adresy trvalého bydliště odstraníte, a jak pak poznáte, komu máte třeba vydat diplom nebo vyplatit důchod?
V zaměstnání se kdysi dávaly peníze na ruku, snad vím, že ten dotyčný něco udělal. Ty další případy, o těch jsem nemluvil, tam řádná identifikace má své místo (na druhou stranu se tam zase sbírají jiné zbytné údaje). Ad ta škola. Po mě diplom chtěli asi tak 3x v životě a to ještě jako formalitu (když už si píšete ty písmenka, což teda nepíšu a v té slavné OP to taky nemám, tak nám ukažte cár papíru). Certifikáty ze školení, pro moji praxi mnohem významější hodnoty, jsem dostal jaksi na jméno bez řádné identifikace (nepamatuju si, že bych kdy v NIC.cz ukazoval jakýkoliv doklad). Ono jaksi lze žít i bez občanek, které u nás do 2 sv. války neexistovaly.
-
Pokud jsou data strukturovaná dle normálních forem, používají se správné datové typy a indexy jsou tam, kde dle prováděcího plánu mají své opodstatnění, tak to nemůže být pomalé. Stejně tak používání funkcí nad datovými typy přímo v db nemůže (by nemělo být) pomalejší než při jejich zpracování v programu (je tam navíc roudtrip mezi serverem a klientem).
Aj ja som si to myslel. Uz som aj chcel robit nejaky benchmark (lebo naozaj neviem, ci DB nepomohol len iny mix zataze), ale nasiel som aj nieco lepsie - niekto to uz skusal aspon teoreticky rozobrat v Sanders, Shin: Denormalization Effects on Performance of RDBMS (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.3530&rep=rep1&type=pdf).
Je treba pocitat s tym, ze je to nieco za cenu niecoho ineho.
Když systém to duplicitní rodné číslo neumožní zadat, tak holt tu pohledávku obsluha zapíše k tomu druhému člověku se stejným RČ, a třeba si to bude nějakou dobu pamatovat.
Tazko niekoho donutite kontrolovat nieco, co sa vyskytuje u niecoho ako 1 z 10k pripadov alebo menej. To z principu nejde - aj ked na uradnicku budete najskor davat pozor, casom si vsimne, ze je to "vzdy spravne" a jednoducho to bude v hlave ignorovat.
A pro to auto si vymyslí jiný VIN, a ten do databáze zadá. Protože je to pořád menší otrava, než to auto neevidovat vůbec.
To u vas normalne funguje tak, ze ked uradnicke nieco nejde, tak si nieco vymysli, aby to nejak preslo? Tomu uz asi nie je pomoci...
Predstavte si, ze idete nieco zaplatit, nejde jej najst, kto ste (alebo nejde vlozit platbu k vam), tak to vlozi k nejakej Alene Jirsakovej, co je hned vedla. Nejde jej to potvrdit Enterom, tak to potvrdi klavesou delete. Nejde jej vlozit 1000CZK, tak vlozi 500 a hned ma zarobene - nie?
-
Když systém to duplicitní rodné číslo neumožní zadat, tak holt tu pohledávku obsluha zapíše k tomu druhému člověku se stejným RČ, a třeba si to bude nějakou dobu pamatovat.
Tazko niekoho donutite kontrolovat nieco, co sa vyskytuje u niecoho ako 1 z 10k pripadov alebo menej. To z principu nejde - aj ked na uradnicku budete najskor davat pozor, casom si vsimne, ze je to "vzdy spravne" a jednoducho to bude v hlave ignorovat.
Jste si jist, že váš komentář nějak souvisí s tím, na co reagujete?
To u vas normalne funguje tak, ze ked uradnicke nieco nejde, tak si nieco vymysli, aby to nejak preslo?
Ne. Když něco nejde (třeba zadat žádost o důchod z důvodu duplicity rodného čísla), úřednice oznámí možnou chybu v systému, problém se analyzuje, zjistí se, že jde skutečně chyba v zadání, vypíše se výběrové řízení na úpravu software (nezapomeňte, že jde o změnu zadání, ne opravu chyby), no, a až tohle celé proběhne, může si dotyčný přijít požádat o důchod znovu.
Ale myslím, že ke zjištění, že se ptáte na pěkný nesmysl, se stačilo trochu zamyslet.
-
Ne. Když něco nejde (třeba zadat žádost o důchod z důvodu duplicity rodného čísla), úřednice oznámí možnou chybu v systému, problém se analyzuje, zjistí se, že jde skutečně chyba v zadání, vypíše se výběrové řízení na úpravu software (nezapomeňte, že jde o změnu zadání, ne opravu chyby), no, a až tohle celé proběhne, může si dotyčný přijít požádat o důchod znovu.
Ne. V české realitě přijde ministr, co si taky chce nahrabat, zadá zakázky kamarádům ve zbrani, ti zbastlí systém postavený jak jinak než na cloudu, lidem se rozdají karty co nikdy nefungovaly a když ano, tak sloužily jako identifikace podlidí a úředníci, kterým není lhostejný osud lidí čekající na dávky umírají ve službě. Úkol byl splněn, softwarová firma a ministr se koupou v bazénu špampaňského, no a co, že podlidi čekají dva měsíce na dávky.
-
Nedivím se, že pak ty IS stojí za starou bačkoru, pokud každý uvažuje takhle...
Nehledě na to, že běžný databáze už jsou fakt trošku zastaralé, je to ta nejprimitivnější část systému.
Neberu psychopaty, který chtějí pomálu v nich spouštět aplikaci (největší problém dneška - obvykle se to celé musí zahodit)
Nedobre se na to divate. Pokud rozdelite programovaci jazyky do skupin: Proceduralni/imprerativni, funkcionalni, deklarativni.
Tak vam spadnou Assembler, Java, PHP do skupiny tech nejjnodussich jazyku. Zajimco deklarativni SQL patri na opacny konec.
Byly doby kdy administratori jako prvni vec po instalaci database vypinali cost-based optimizer. Dneska po cca 15ti letech dokaze clovek vymyslet lepsi exekucni plan jen ve vyjimecnych pripadech. Tech 15 let je adekvatni doba na vyvoj takoveho software.
Lidi jako vy nadavaji, ze databaze jsou zastarale, ne-objektove a kdovi co jeste.
A presto je pouzivaji - pritom si vubec neuvedomuji, ze to co dela SQL pohodlnym je prave ta deklarativnost jazyka. Diky tomu se dokonce aplikace muze sama prizpusobit datum nad kterymi pracuje. Dokazal byste takovou vec udelat v nejakem "modernim" jazyce?
Dneska se SQL cpe i klasickych imperativnich jazyku http://msdn.microsoft.com/en-us/library/bb397895.aspx (http://msdn.microsoft.com/en-us/library/bb397895.aspx)
-
Ked mate pocit, ze ste najmudrejsi na svete
Nemusim byt najmudrejsi na svete - staci, ze to mam zarucene od vyrobcu, normami, zakonami a celymi procesmi.
....
Zrejmejsi pripad overengineeringu je snad uz len overovanie po kazdom riadku kodu, ci este svet neskoncil.
Ono je to jednoduche:
- bud taky pripad nenastane a mozte si nahovarat, ze mate univerzalnu pravdu
- alebo to nastane a vyrobite problem znacne prevysujuci uspory sposobene Vasim non-overengineeringom
Aplikacii spoliehajucich sa na prirodzene kluce je cela hrst a vacsinou sa tam problem zjavil.
Ano, praktická zkušenost to bohužel je. A na základě této praktické zkušenosti potom vznikají situace, jako že je třeba vymáhána pohledávka pro zcela jiném člověku podobného jména nebo bohužel neunikátního rč a nikdo se nenamáhá to řešit. Do systému to naťukat lze, počítač řekl, že dlužíte, tak plaťte.
Skuste to co som napisal precitat este raz. Je tam slovo "unique".
-
Když systém to duplicitní rodné číslo neumožní zadat, tak holt tu pohledávku obsluha zapíše k tomu druhému člověku se stejným RČ, a třeba si to bude nějakou dobu pamatovat.
Tazko niekoho donutite kontrolovat nieco, co sa vyskytuje u niecoho ako 1 z 10k pripadov alebo menej. To z principu nejde - aj ked na uradnicku budete najskor davat pozor, casom si vsimne, ze je to "vzdy spravne" a jednoducho to bude v hlave ignorovat.
Jste si jist, že váš komentář nějak souvisí s tím, na co reagujete?
Pomerne ano, akurat som to asi dost dobre nevysvetlil - ked vam nejaky system dovolit robit duplicity, ale tie budu vzacne, tak sa k tomu uradnicky budu stavat, ako keby tam duplicity neboli. Takze sanca, ze sa to pripise inemu, je aj pri dovolenych duplicitach jednoducho velka.
To u vas normalne funguje tak, ze ked uradnicke nieco nejde, tak si nieco vymysli, aby to nejak preslo?
Ne. Když něco nejde (třeba zadat žádost o důchod z důvodu duplicity rodného čísla), úřednice oznámí možnou chybu v systému, problém se analyzuje, zjistí se, že jde skutečně chyba v zadání, vypíše se výběrové řízení na úpravu software (nezapomeňte, že jde o změnu zadání, ne opravu chyby), no, a až tohle celé proběhne, může si dotyčný přijít požádat o důchod znovu.
1. ked si nahodou urady spojuju medzi sebou cloveka podla rodneho cisla, tak vam (z pohladu autora SW) extra identifikator vo vasej DB nic nepomoze. A ked sa to spojuje podla ineho unikatneho identifikatora, tak je snad kazdemu na prvy pohlad jasne, ze ma byt primarny kluc ten unikatny identifikator.
2. Toto sa riesi zmenou rodneho cisla - a tlak je naozaj velky, aj ked vymena dokladov nie je nic prijemne.
- alebo to nastane a vyrobite problem znacne prevysujuci uspory sposobene Vasim non-overengineeringom
...co je len zlomok nakladov, ktore dokopy vzniknu aj pri overengineeringu uz z principu toho, ako sa komunikuje s okolim ;). Ono aj s tym koncom sveta je to tazke - co ked nahodou nastane a PC budu mat dalej nieco pocitat? ;)
Mne sa skor zda, ze sa pre istotu vytvara kopec kodu, az to dopadne takto:
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
(na zasmiatie; evidentne ispirovane tym, co sa robi v "enterprise" aplikaciach)
Aplikacii spoliehajucich sa na prirodzene kluce je cela hrst a vacsinou sa tam problem zjavil.
Vyrobne cislo (tu VIN) nie je prirodzeny kluc - je robeny tak, aby bol unikatny. Vdaka hierarchickemu deleniu a velkemu priestoru cisel to ani nie je problem zarucit (na rozdiel od rodnych cisel).
-
Toto sa riesi zmenou rodneho cisla - a tlak je naozaj velky, aj ked vymena dokladov nie je nic prijemne.
Jak budu řešit změnu rodného čísla člověka, kterého už ho budu mít zavedeného v databázi (včetně spousty provázaných záznamů)? Když rodné číslo nebudu mít jako primární klíč, jde o jednoduchý update. A jak to budu řešit když jsem v nějakém pomatení mysli odmítnul zavést pořádný primární klíč a zneužil jsem pro primární klíč rovnou to rodné číslo? Jednoduchý update nepůjde, protože mi na ten primární klíč (rodné číslo) budou ukazovat cizí klíče z jiných tabulek => průšvih!
-
Jak budu řešit změnu rodného čísla člověka, kterého už ho budu mít zavedeného v databázi (včetně spousty provázaných záznamů)?
Staci si precitat prvy bod.
V kratkosti: ak je unikatny identifikator v statnych evidenciach rodne cislo, tak si nepomozete; ak nie, tak nie je dovod davat do primarneho kluca rodne cislo. V prvom pripade u vas sice nastavite, ze mate 2 roznych ludi, ale podla ostatnych uradov to bude len jeden a nebudete vediet, o kom dostavate info (v horsom pripade vsetci viedli 2 rozne sady informacii pod 1 clovekom) => cele odlisenie je vam aj tak nanic.
A co som videl v praxi len ako pozorovatel, tak duplicitne rodne cislo u dvoch dievcat s rovnakym menom a datumom narodenia sa riesilo tak, ze obidve dostali nove doklady vratane rodne listu. Cele to vyzeralo viac na zalozenie noveho cloveka ako zmenu nejakych cisel.
-
Změny RČ u lidí - ať už skutečné či jen oprava překlepu obsluhy - se dělají velmi často. Nejde o "nějaké odlišení v tomhle IS" - naopak, jde o uvedení do správného stavu, aby tím novým RČ šlo toho člověka provázat s externími systémy.
Či lidé bez RČ či s duplicitou (vyberte si): někdo si na vaší ukradenou občanku založí úvěr. A vy taky. Pod jakým(i) RČ mají být tyto dva úvěry evidovány?
U VINu dochází k velkému množství překlepů. A jsou registrovaná vozidla, která VIN nemají vůbec. Např. historická, či "doma dělaná" (třeba když si postavíte doma přívěsný vozík).
Svět není tak jednoduchý, jak na první pohled vypadá... Debatu zda má být logika v databázi či aplikaci nebudu rozdmýchávat, je to vlastně debata, co z nich tady bude déle a jak se k těm datům budou dostávat jiné aplikace.
-
K problému unikátnosti: pred pár rokmi niekto zaviedol číslo účtu aj s predčíslím ako identifikátor. A bolo jasné že musí byť unikátny. Až raz prišiel IBAN...
-
>> student
Já bych řekl, že ještě nemáte dostatek zkušeností.
Rodné číslo nebo VIN je dostatečně unikátní identifikátor na to, aby mohl fungovat v reálném světě bez větších problémů. Jako identifikátor společný pro různé aplikace v různých institucích je zcela vyhovující a případné duplicity se mohou vyřešit jinak - systémově (když narazíme na duplicitu, rozjede se úřední postup "Změna rodného čísla podle § 455-23-a"), nebo nesystémově (napíše se tam něco jiného).
Informační systém je modelem reality. Realitu nemusí nijak zajímat, jak mám model implementovaný, takže si můžu, a dělám to, do modelu zavést vlastní primární klíče, přes které pak propojím další tabulky. Úřednici implementační detaily nezajímají, ta se o existenci nějakého interního klíče nikdy nemusí dozvědět. Na venek se aplikace tváří, že RČ je "unikátní" a dostat tam duplicitu může být možné až po nastartování výše zmíněného úředního postupu "Změna rodného čísla".
Zopakuji vám to ještě jednou: Realitu nezajímá, jak je váš model implementovaný.
A ještě to rozvinu: Je-li modelování reality schůdnější a levnější přes zavedení vlastních klíčů, není důvod lpět jiném řešení.
-
To je neuvěřitelné, jak se lidi dokáží hádat pořád dokola. Zvlášť když celý problém leží v tom, že tu máme ve skutečnosti dvě pravidla:
- Vždy používat přirozené primární klíče, pokud je to možné.
- Přirozené primární klíče z problémové domény v 99% případů není možné použít.
Pokud se druhé pravidlo ve školní výuce neobjevilo, je to rozhodně chyba a stěžoval bych si (my jsme ho v DB1 měli, rodné číslo je doslova učebnicový příklad).
Pokud někdo nezná první pravidlo a slyšel vždy jen poučky typu "každá tabulka musí mít autoincrement" tak je začne dávat fakt všude, včetně například m:n vazebních tabulek (to by mě čert vzal, když to vidím, jelikož tam samozřejmě nikdy není ani ten UNIQUE index).
-
nic z toho co se tazatel pta nedelam a nikdy jsem to nedelal. Ono by to ani neslo, na skolach se o databazich, s kterymiu pracuji co vim nic neuci. Ale to jen na okraj
Tazatel zjevne zjistuje rozdil mezi teorii a praxi u sql-databazi. Ano, ten zde je a ma sve duvody. SQL-databaze byly vyvinuty pro komplikovane zpracovani velkeho mnozstvi dat v transakcnim prostredi. V takove situaci akceptujeme, ze se datbaze nejdrive tezce zamysli, zda je takovy nejaky komplikovany dotaz vhodny, syntakticky spravny a ze se pak se venuje vyvoji strategije, jak na to pujde. To stoji cas, ale to jak receno akceptujeme, nebot pote bude datbaze valcovat stamiliony radek a to ve vlastni rezii. Vzhledem k tomu, ze to vsechno musi probehnout v nejake transakci, tak to vpodstate realne ani nelze jinak udelat.
Ve vsech ostatnich pripadech, tedy v 95% vsech beznych aplikacich na tomto svete to neni potreba. A lide intuitivne funguji tak, ze kdyz neco neni potreba, tak se tomu nevenuji.