Databazy - programovanie/spravovanie

[Pavel Stěhule]

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.

[Reklama]

[Filip Jirsák]

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

[Tomáš Crhonek]

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

[Tomáš Crhonek]

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

[Tomáš Crhonek]

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

[Reklama]

[Tomáš Crhonek]

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

[Filip Jirsák]

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.

[Tomáš Crhonek]

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.

[Filip Jirsák]

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

[Tomáš Crhonek]

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

[Filip Jirsák]

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

[Tomáš Crhonek]

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.

[Filip Jirsák]

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?

[Tomáš Crhonek]

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.

[student]

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.

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?