Hm, co se týče IT státních organizací, tak je to jedna bota za druhou. Tohle, IS MPSV, digitalizace fondu národní knihovny, tragikomedie jménem IZIP.. Sypu si popel na hlavu, za to, že jsem v minulosti zpochybňoval kvality ČUZAKU. Jejich spuštění RUIANU ve vfr, bylo ukázkou kvalitní práce a profesionálního přístupu. Parádně zpracovaná dokumentace, komunikace, všechno výborný. Fakt, chlapi z ČUZAKu, klobouk dolu. A i v minulosti s nima byla pohodová, ale hlavně rychlá a věcná komunikace. Ale zpátky k tomu registru. Tohle se množí jako hmyz, protože ty informační systémy se daj nejvíc ojebat, tu díru do země je třeba skutečně vykopat, ten beton se tam nějakej taky musí nalejt, ty letadla co se koupí musej aspoň trochu lítat apod. U těch IS se to okecá bezpečností a já nevim čim. Další problém je, že se tohle outsourcuje, to je, podle mě největší kravina. Na tohle maj mít vlastní oddělení, který se bude starat o datový centrum, tohle musí dělat někdo, kdo ty data zná, zvlášť když je v nich historickej bordel.
No, tuhle otázku jsem si položil taky. Podle mě to bude v řádu desítek tabulek, počítám, že maximálně několik desítek milionů záznamů v jedný. Jako, ve světě databází tohle neni žádnej obr. Podle mě i ty blbý slevový kartičky do Teska musej mít větší objem dat, aby mohlo tesko spočítat, jestli si lidi koupí míň rohliků, když podražej o pětník. Tady bude hlavně mazec nastavení práv několika různejch druhů klientů, asi nějaký logování změn apod. Ale to všechno jsou věci, na který existujou hotový řešení, neni to žádný posílání apola na měsíc. Existuje mrtě firem, který tohle uměj udělat a dělaj to. K těm IT oddělením u úřadů, jde o to, že na tyhle lidi nemaj prostě tabulku a za úřednickej plat tohle nebude člověk, kterej něco umí, dělat.
Jak uz sem psal, evidenci aut by napsal zacek ZS za vikend - a to vcetne otestovani a zprovozneni. Samo vcetne logovani zmen - co je tak tezkyho na tom insertovat do tabulky a nic nemazat/nebo updatovat, ze ... A kolik asi takovych zmen jedno auto za svoji zivotnost vygeneruje ... 10?
Jakejch pak deste tabuek? Na Idnesu psali neco o tom ze je problem v tom, ze je nekde dodavka a nekde dodavkovy automobil. Takze misto relacni tabulky bude jen nejakej VarChar. Pak se neni ani cemu divit, ze to ma 500GB.
Predpokladam, ze test bezel na jednom excelovskem sesitu a pak to nejaky tupy studentik zakladni skoly dle SQL dokumentace prevedl na jednu SQL tabulku.
Ten varchar to byl v minulém systému, otázka je, nakolik se to při migraci čistilo a co z toho čištění vypadlo...
A k tomu testu na jednom sešitu - a dal vůbec zadavatel k dispozici data předem, nebo se oháněl bezpečností (a neschopností)?
A kdo tedy podepsal převzetí do provozu, když tam je takový bordel v datech?
Jasně že to jde, i já jsem zrovna minulý pátek migroval pro jednu nejmenovanou banku jeden systém obdobné složitosti. Ale dokážu si představit, že na to bylo málo času, zadavatel anonymizovaná data nedal, původní aplikaci už nikdo nic nerozuměl atd.
Já s takovým zákazníkem dělat neumím a proto nedělám pro státní správu. Ale ATS Telecom na státních zakázkách žije, tak by s tímhle počítat měl.
Jinými slovy - dokážu si představit objektivní důvody, proč to bylo těžké. To ale není omluva, to se prostě musí (projektově) uřídit.
Převzetí nikdo nepodepsal a o bordelu v datech se vědělo ještě předtím, než se to vůbec spustilo - http://www.isvzus.cz/cs/Form/Display/343682
ATS to mělo opravit, samozřejmě se na to za mrzkých pár desítek mega vysrali, že.
Jestli máte na mysli http://en.wikipedia.org/wiki/Apollo_Guidance_Computer , tak mám pocit, že 386 byla přece jenom několikát rychlejší.
Nejlépe se ale zřejmě vydělává na údržbě, viz.: http://www.soom.cz/index.php?name=articles/show&aid=581