Vlákno názorů k článku Portál veřejné správy: první dojmy od michal - Myslim, ze autor narazil na dulezity problem drahych...

Myslim, ze autor narazil na dulezity problem drahych a slozitych portalovych reseni.

Manazeri se totiz daji lehce premluvit od obchodniku velkych firem, ze za relativne malo (napr. 2 miliony) dostanou uzasne funkcni a rozsiritelne portalove reseni zalozene na nejnovejsich standardech. Povzbuzeni kvalitnim marketingem velkych firem pak dostanou system, ktery je pouze zaklad pro portal, ktery potrebuji, je neuveritelne slozity, silene hardwarove narocny (Zajimalo by me na kolika strojich tento portal bezi. Ze by 12? Maximalne 2000 uzivatelu najdnou?) a drahy na vyvoj (vsechno v Jave).

Delam v soucasnosti na projektu portalu ktery bezi v systemu Oracle 9iAS Portal, coz je konkurencni produkt pouzite technologie, a odberatel dostane za celkem cca. 5 milionu dynamycky web s kvalitni spravou uzivatelu, ktery si bude moci spravovat sam + pet apikaci (portletu) udelanych na zakazku. Problem je proste ve vykladu slova portal. Nedovedu si predstavit, ze by nejaka firma (napr. Centrum, Atlas atp.), ktera to mysli s vyuzitim sluzeb portalu vazne by mela na to pouzit takoveto reseni...

A navic, kdyz ten radoby portal od velke drahe firmy XY potom nesplnuje ocekavani, dotycny manazer rekne: "Vidite, delala to XY, a ani tak to nefunguje." Kdyby to ten manazer zadal 100x mensi firme za 50x min penez se stejnym vysledkem, mel by OSOBNI pruser...

Souhlasim, presne takhle funguje "manazerske" rozhodovani.

My mame reseni s MS SQL pro Seznamka.cz a Rande.cz - ve spickach tam byva az 6.000 lidi soucasne a to vse za 1.000.000 Kc.
Jiz pouha volba Oracle se pekne prodrazi, protoze programatori i bezny provoz Oracle je mnohem drazsi nez MS SQL a o MySQL nemluve. Obdobne je tomu s produkty IBM.

Samozřejmě vím, že pro mnoho lidí je označení MySQL zkratkou pro open source SQL server. Ale opravdu si nemyslím, že tohle by byla aplikace, kde by mělo smysl uvažovat o nasazení MySQL. Příště jako příklad raději uveďte Firebird nebo PostgreSQL.

Jak jsem se vcera dozvedel u piva, tak MySQL uz dneska umi triggery, transakce apod... Takze proc ne?

---

Nicmene myslim, ze o databazich tu rec neni, ty nejsou ani tak narocne ani tak drahe. Jde spis o Enterprise verze aplikacnich serveru - neuveritelne slozite systemy - ktere ve vysledku slouzi jako jednoduchy redakcni system.

Pane Pallas, hovorite o tom rande.cz, ktere ma trvale potize s vykonem, po pulnoci je casto "na brise" a bezmocne mava nozickama?

To, že MySQL umí triggery, jste se mohl možná dozvědět u piva, ale v tom případě s vámi na to pivo měl jít někdo z autorů - oni to totiž sami ještě nevědí, jinak by se o tom na svém webu určitě zmínili. Ostatně bych považoval za poněkud zvláštní, pokud by databáze uměla triggery a neuměla stored procedures. A to je jen špička ledovce - obecně platí, že chcete-li udržet integritu dat, musíte to dělat na straně klienta. Což je v tomto případě (velký počet klientů, potenciálně různých) poněkud nešťastné.

A s těmi transakcemi je to také všelijaké. Pokud transakce potřebuji (jako že ano), poohlédnu se raději po databázi, která je podporuje nativně, ne po databázi, kam byly dodatečně, neochotně a po mnohaletých prosbách uživatelů doplněny za cenu použití jiného typu tabulek, s nímž nechodí jiné funkce.

Aby bylo jasno: netvrdím, že MySQL je k ničemu. MySQL je vynikající nástroj pro svou oblast použití. Tou jsou aplikace, kde je poměrně jednoduchá datová struktura, převažují selecty a s daty se manipuluje relativně málo a ne konkurenčně. Tam je MySQL doma a tam dosahuje špičkových výsledků. Ale aplikace, o které se bavíme, takovým případem není. Pokud by se mělo o open source řešení, rozhodně by lepší volbou byl Firebird nebo PostgreSQL.

Jinak máte samozřejmě pravdu, že databázový engine je jen jednou (a zdaleka ne nejdražší) komponentou toho systému. Reagoval jsem jen na zmínku o MySQL, která je v tomto kontextu podle mých zkušeností hodně mimo.

Pane anonyme, pokud jste mel nekdy problemy je to mozne, protoze ty ma obcas kazdy. Nozickama vsak muze klidne klepat Casablanka pres kterou jsme pripojeni a nebo take vas aparat.

Pane kolego, trochu si protirecite. Portal statni spravy je jak zde jiz bylo vicekrat receno predevsim hora dokumentu a informaci. Tudiz predevsim selecty.

Vas rozklad o transakcich je rovnez nepresny - transakce nema na strane klienta co delat, ale to se statni spravou nijak nesouvisi.

Ulozene procedury a Triggery planuje MySQL od verze 5 - cituji z www.mysql.com: Stored Procedures and Triggers Stored procedures are being implemented in our version 5.0 ..... based on SQL-99 konec citatu.

Ostatne ti hosi co v Uppsale v MySQL pracuji maji na co navazovat. DBMS Mimer vznikl na Uppsalske univerzite na zacatku osmdesatych let /v te dobe jsem tam mel cest studovat informatiku/. Mimer existuje v Uppsale dodnes a kolem nej vznikly desitky firem a mnoho set odborniku pracujicich s jadrem RDBMS.

Na zaver opakuji, ze Oracle je prilis draha hracka pro vyvoj i provoz systemu, ktery neni typu OLTP, coz gov.cz opravdu neni.

1. Jak jsem vyrozuměl z článků o portálu státní správy, mají si tyto informace spravovat příslušné úřady a instituce samy. Takže tu máme poměrně velký počet klientů, kteří budou s daty manipulovat. A samozřejmě často i současně.

2. Kde jsem, prosím, tvrdil, že transakce je na straně klienta? Pouze se domnívám, že v okamžiku, kdy se stejnými daty manipulují současně různí klienti, bez transakcí to dost dobře nejde. A moje zmínka o transakcích v minulém příspěvku byla pouze reakcí na to, že se o nich zmínil kolega, sám bych s nimi nezačal.

3. Jenže ta vaše verze 5 je zatím pouze ve stádiu vývoje, daleko před dokončením, byť jen testovacích verzí. Takže MySQL podporu stored procedures ani triggerů nemá. Prostě nemá, tečka.

4. No a? Já hodnotím použitelnost MySQL, napsal jsem, k čemu se hodí a k čemu ne. Zkušenosti jejích tvůrců s tím mají co dělat relativně málo, to je otázka designu, pro který se na počátku rozhodli. Tedy maximální jednoduchosti a z toho vyplývající rychlosti na úkor náročnějších funkcí. Že se později pod tlakem rozhodli na původní design nalepit prvky, se kterými se původně (záměrně) nepočítalo, tím lze důsledky toho rozhodnutí pouze omezit, nikdy ne úplně odstranit - leda by začali znovu od začátku.

5. Otázka nikdy nezní pouze tak, zda MySQL nebo Oracle. Existuje mnoho dalších projektů, ať už open source nebo komerčních (a různě drahých). Každý má své silné a slabé stránky, každý se pro něco hodí více, pro něco méně. To, že tvrdím, že se pro tento typ aplikace MySQL nehodí, přeci vůbec neznamená, že se domnívám, že je nutné použít Oracle. Nic takového jsem nikde nenapsal, tak mi to, prosím, nepodsouvejte.

No ale vite jak pekne by to mozna bezelo, kdyby se updaty a master data drzela v nejake velke databazi a jednou za cas (treba klidne jednou za den, tam se v zasade asi nic moc interaktivne menit nebude) se prelila do male databaze ze ktere by se generovaly ty webove stranky. A kdyby bylo v roli te male databaze MySQL tak by to bylo za hubicku (ta velka databaze by mohla mit treba jen 10 licenci, vice lidi tam tezko bude delat update soucasne).

Pokud by se stalo, ze by si Mysql pod sebou zborilo tabulky, proste by se obnovily z te master databze, mysql je nevsedne rychle kdyz jde o to nahrat databazi z mysqldumpu.

Ja bych si umel predstavit dokonce variantu, kde by vsechny stranky byly staticke a proste by se generovaly z databaze. To by teprve resitele videli ten fofr jakym umi apache servirovat stranky. A ministr by se nemohl vymlouvat na zle hackery co mu na to delaji DOS utoky. Ostatne websphera tohle umi, jedna jeji komponenta zvladne to, ze serviruje uzivatelum stranku nabranou z databaze z cache bez toho, aby se do databaze udelal jediny hit. Nicmene vzhledem k prevratne rychlosti portalu na ni asi nezbyly penize. On by reverzni proxy umel i squid, ale ten by se z tech URL asi zblaznil.

Ano, pokud by se to udělalo takhle, byla by MySQL velmi dobrou volbou pro příslušnou část řešení.

Ano vsechny urady si to budou spravovat samy, ale predpokladam, ze ve vlastnich systemech. Na zacatku devadesatych let jsem stavel registr obyvatel pro vnitro /vyhral jsem vyberove rizeni proto, ze jsem byl 3x levnejsi nez ceske firmy/ a a to reseni bezi dodnes - Informix na Unixu. Delal jsem potom dalsi velke databazove systemy pro ministerstvo financi, napriklad registr ekonomickych subjektu. Takze mam predstavu co je mysleno tim spravovanim systemu jednotlivymi urady - proste kazdy si chce utracet sve penize sam. Tudiz predpokladam, ze GOV je v podstate rozcestnik kombinovany v lepsim pripade s OLAP systemem, tedy nutnost transakci je nulova.
Jeste takova zajimavost - transakce registru obyvatel a patrne i na ostatnich uradech jsou komplikovanejsi nez pouze provedeni commitu. Jelikoz vetsina ukonu ve statni sprave nabyva pravni moci az po urcite dobe, je samotna databazova zmena vazana jeste touto dobou, do kdy plati stare udaje a teprve pokud nekdo neprijde s odvolanim a pod, tak nabude transakce platnosti. Tudiz je mozno videt on line transakce pouze jako frontu pozadavku a na to nepotrebujete take zadne velke transakcni schopnosti.
V meme puvodnim prispevku jsem mluvil o tom, ze Rande a Seznamka jedou na MS SQL a kazdy den tam bez velkych problemu probehne 1,5 milionu on line transakci. Tudiz by stacil i ten Gates, ktery je mnohem levnejsi nez Oracle, ma vetsi pocet dostupnych programatoru a techniku a tudiz je pro takoveto nekriticke systemy plne dostacujici.

Proti tomu, že jste ukazoval jako alternativu MS SQL, jsem také nic nenamítal (jediná námitka, kterou bych proti němu měl, je značné omezení použitelných platforem, na kterých běží). Nenamítal bych nic ani v případě, že byste zmínil Sybase nebo Interbase. Nelíbila se mi pouze zmínka o MySQL, která se podle mne v tomto případě vůbec nehodí (a transakce jsou jen jedním z důvodů); pokud už open source řešení, spíš bych jako alternativy viděl zmíněné dva systémy (Firebird, PostgreSQL). Je to dáno tím, že jsem dost alergický na to, že většina lidí, chce-li zmínit open source řešení, jako databázi okamžitě navrhuje MySQL; přitom MySQL rozhodně není nějakým prototypem, je to velmi specifický SQL server s velmi specifickou oblastí využití.

To posledni je jak to dnes resim ja - proste staticke dokumenty. Jenze to taky nekdo nesmi byt lemra a musi zamakat na adresach - v takovem pripade uz totiz musite mit jedinecne nazvy souboru.

A ty adresy s URL>=200 znaku by to asi sranda nebyla ;)

Nezlobte se, ale musím se do vaší plodné debaty vložit. Nechtěl jsem v článku zmiňovat *nějaké* opensource řešení, které mě jako první napadlo, ale jako extrém jsem úmyslně použil to "nejprostší" a "nejhloupější" známé řešení - tedy mySQL. Stejně tak dobře jsem mohl se stejný efektem uvést, že to celé může být postaveno na statických souborech uploadovaných přes webové rozhraní... Což ani v jednom případě nemůže soudný člověk brát jako možné reálné řešení, ale jako nadsázku vystihující podstatu věci.

Ani to neni tak moc nadsazka, protoze cast toho co se ve statni sprave produkuje jsou dokumenty, ktere by klidne mohly byt publikovany jako soubory. Pripadna data jsou nejspise repliky nebo vystupy ze zdrojovych systemu jednotlivych uradu a pro jejich ulozeni by jiste stacilo XML nebo nejaka jednoducha DBMS. Cele reseni je typicky vysledek prace lidi, kteri utraci danove penize. Z obchodniho hlediska je to postavene uplne na hlavu, protoze poctive vyberove rizeni by melo hledat provozovatele, ktery by ze systemu generoval zisk.