Databazy - programovanie/spravovanie

[student]

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.

[Reklama]

[Kolemjdoucí]

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.

[Někdo]

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í.

[student]

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"?

[Kolemjdoucí]

jednoducho nerealne, ze by to zmenili.

  Nereálné je výhradně porušení fyzikálních zákonů.

[Reklama]

[Filip Jirsák]

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.

[Někdo]

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.

[student]

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)

[Někdo]

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.

[student]

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.

[zboj]

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.

[podlesh]

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.

[Jan Forman]

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)

[Pavel...]

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.

[student]

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.