Databazy - programovanie/spravovanie

[Filip Jirsák]

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.

[Reklama]

[Tomáš Crhonek]

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.

[Ivan]

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

[Pavel...]

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

[student]

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

[Reklama]

[Někdo]

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!

[student]

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.

[v.sp]

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.

[iban]

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

[Petr Bravenec]

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

[podlesh]

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

[Vratislav]

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.