Vlákno názorů k článku Letmý pohled na Alfu MySQL 5.0 z pohledu postgresisty od Johann - vsechny tyto vymozenosti, ktere jsou popisovany vyse a...

vsechny tyto vymozenosti, ktere jsou popisovany vyse a povazovany za pokrop sleduji s velkou skepsi.

Zazil jsem nasledujici - v jednom vetsim projektu (nakladatelstvi - projekt 50 lidi, Informix) s komplikovanym db-modelem nakonec vedel vpodstate jeden (matematik a rekl bych s velkou schonosti abstraktniho mysleni) jediny clovek, jak vse s sebou souvisi. 49 lidi mu pricmrdovalo a kdyz se sef firmy chtel neco zeptat, tak se plazil pred tim guru v kancelari na zemi.

Nebylo vubec mozne praci rozdelit, sql-parser porad hlasil, ze jsou mu prikazy prilis komplikovane. A pri rekurznich problemech se data stejne natahla do pameti.

Muj zaver je, ze s temi vsemi moznostmi ktere dnesni databaze nabizeji je 99% i programatoru za hranicemi svych moznosti. Je to mozna teoreticky pekne, ale v praxi je to k nicemu, protoze neni mozne aby ve vsech projektech sedeli jenom Einsteinove.

Tim samozrejme nesnizuji uroven clanku. Jen mi to pripada trochu teoreticke a a jako vhodny doplnek k takovym prispevkum bych se rad take dovedel, jak to nakonec vypada v praxi, jake jsou zkusenosti.

Priklady:
paja:
o mysql se zatim jeste nemusi starat, nic svetoborneho. Nebo je to jak napsal take nekdo nahore, ze ty vymozenosto oracle vpodstate nikdo nevyuzije?

jerryIII:
vsechno by nandal do SP. Je to vubec mozne, jak z hlediske technickeho, tak z hlediska spravy projektu. Je to u modularniho software s vice dodavateli mozne?.

nebo to zalohovani za provozu - neni to tak, ze 99,5% vsech aplikaci sveta ma o pulnoci volno a jen 0.5% (SAP, vojaci, NASA a dalsi) musi byt schopno bezet furt?

Jeste k te bezpecnosti: Zatim jsem zazil 4 totalne rozhozene databanky. 3 x Oracle 1 x informix. Ve dvou pripadech se zblaznil raid a napsal 'transakcne pojistene' uply srot na harddisky. V dalsim pripade chtel vymenit admin vadny harddisk v poli a vytahl ten jeste fungujici.

V tom poslednim pripade byla ta databaze take k nicemu, protoze v projektu si dali zalezet, aby bylo vsechno pojistene (transakce) a navrh db byl takovy cisty a uplne normalizovany - no nic naplat pri inventure bernak tuto neuznal, protze zamestnanci sklad silne vykradli - predstavenstvo bylo uplne vydrene - jak je to mozne - ta databaze stala tolik penez. (a konzultanti meli vzdy sako a kravatu)

Jeste jednou , neni to kritika, pouze vyzva, ze by bylo zajimave slyset i nazory z jineho tabora.

Je skorem prima umera mezi starim sw a potrebnym mnozstvim znalosti k tomu abyste sw rozumne ovladal. Naucit se pouzivat tridy v dot NETu, to chvili trva. Stale je to ale remeslo, ktere se necha naucit. SQL , SP to prece jeste nejsou zadny Hi technologie.

Nicmene zminene vymozenosti by meli zivot spis zjednodusovat, sam tomu verim :->. Jen tim, ze nemam SQL prikazy rozesete po cele aplikaci se aplikace zasadne zprehledni. Nesmi byt ale programator PRASE. Protoze je to pro nej prace navic, ktera se vrati az pozdeji. Rok zpatky jsem se tu bavil s nekym a presvedcoval jej o vyhodach SQL vuci klasickemu XBase programovani. SQL je sice pomalejsi, ale kdyz jej umim pouzivat a cist, tak na prvni pohled vidim, co chtel autor vyjadrit - pokud ovsem taky umel pouzivat SQL (ne kazdy jak jsem poznal je sto se jej naucit).

Taky jsem zazil par zmrsenych projektu. Hlavni problemy bych videl asi nasledujici:

1. Zakaznik i resitel nemaji skutecnou predstavu, co dana technologie umi.

2. Programatori neumi danou technologii poradne ovladat a uci se za chodu. Je to zacarovanej kruh. Protoze jim furu casu zabere prorazeni nejruznejsich pitomosti, nemaji cas na skoleni X ruzna kvalita a cena skoleni, kvalita a cena dokumentace. Polovicka programatoru a adminu jsou stary jesitove, ketry si mysli, ze jedini znaji pravdu, jelikoz maji deset let praxe, osameli vlci. Pokud je nevyhubite, tak Vam rozbijeji tym.

3. Totalne nevyvazene projekcni tymy, nesmyslne projektove rizeni, atd. Kratce a nahodou jsem se zucastnil projektu v Anglii, ktereho se zucastnilo cca 100 az 200 vyvojaru. Odhaduju, ze na kazdych deset, byl jeden dalsi co psal dokumentaci, dalsi co rikal, co maji delat, dalsi zkousel, testoval. Jak to vypada tady v Cechach?

Vcera jsem si listoval ve starych skriptach. Tehdy, na zacatku 80 let se odhadovalo, ze pet procent pricin chyb je v hw, os, podpurnem sw. To dneska uz neplati. Mam ale pocit, ze problemovych projektu spis je vic, protoze je min casu, penez, vic trotlu, kteri se kolem toho toci :->.

Ad posledni. Kde nic neni ani smrt nebere. Zadny IS potazmo databaze nezachrani podnik pred krachem, pokud je k tomu podnik odsouzeny neschopnosti svych sefu, zamestnancu, osudem

Souhlasim, ze "advance" vlasnosti v SQL nejsou na skodu a co jsem zazil tak se pouzivaji i kdyz treba SP ne v takove mire. Dulezite je mit moznost rozsirit SQL server a nebyt na vzdy odkazan na to co vyvojari daneho SQL povazovali za dulezite.

Problem "guru" v projektech je obecny problem a pokud se podivate na libovolny soft tak na zacatku kazdeho takoveho projektu nejaky "guru" byl. Problem je pokud projekt zustava v tomto obdobi. Pak to zacina byt o neschopnosti nekoho ridit projekty a organizovat praci. Bohuzel prave vnitrni organizace firem a projektu je ten nejvetsi problem co v CR (a nejen) znam. Vetsina firem se orientuje smerem ven na obchod a zakazniky, ale vnitrne je znacne nefunkci a neefektivni. Casto je to tim, ze manageri si neumeji korektne ohodnotit veci ktere bezprostredne nenesou penize.

sice se s Vami a s panem Zakem v mnohem shodnu, zejmena v tom, ze situace neni (projektove) ruzova. Co se mi asi nepodarilo sdelit je, ze ja si na rozdil od vas nemyslim, ze se to da vyresit lepsim managementem.

V mem priklade uvadeny 'guru' byl vpodstate spravne na svem miste. Nekdo ten komlikovany navrh udelat musel. Problem je v systemu - vy mozna dokazete z popisu tabulek zjistit co tim autor minil, ale vetsina to nedokaze. A pak se okolo toho motaji - jak jste popsal.

Ale ten UPLNY dukaz meho tvrzeni poskytuji ty vsechny db-newsy. Kdyz si to proctu, s cim se tam kazdy den nanovo zapasi, tak musi byt kazdemu jasne, jak musi to software vypadat. A je to i logicke - lide kteri nemaji ten dar abstraktne myslet se umi vetsinou lepe prodat u zakazniku. A ja si myslim ze je to i spravne - software musi mit moznost psat kazdy - ne jen doktor ved. A proto jsem presvedcen, ze kdyz se tomu stadu ( a ja se k nemu pocitam take) predhodi dalsi "advanced" o to vice to pujde do te slepe ulicky, jak jsem napsal.

Stored procedures IMHO modularitu spíše podporují. Je to něco podobného, jako když se v OOP přistupuje k datům třídy pouze přes metody, takže každý vývojář nemusí neustále hlídat, co všechno je potřeba aktualizovat, když změním určitou konkrétní hodnotu. Zrovna tak je to u té databáze, kde je tak možné zajistit, aby se při určité operaci s daty automaticky provedly všechny side-effecty. A hlavně: pokud potřebuji přidat nějaký dodatečný důsledek, přidám ho jen do té procedury, nemusím procházet celou aplikaci (resp. všechny klientské aplikace) a zkoumat, kde všude se ta data mění.

ok, rozeberme to. Nejdrive se zastavme u vasi poznamky [..]resp. vsechny klientske aplikace [..]

Klient nejake aplikace (napr. pro podnik. inf. system) je samozrejme vytvoren tak, ze nema s nejakou databazi - jeste lepe dokonce s nejakou konkretni aplikaci vubec co do cineni. Priklad takoveho klienta je neco, o co se snazi myslim pan Zak ve svem MAPE projektu vytvorit - nebo to uz je snad i hotove.

SP je nejaky kus kodu - vesmes s velmi primitivnimi jazykovymi moznostmi (polemika) s tim, ze je mozno vyvolavat SQl prikazy. Moje otazka:
jak zni SQL prikaz, kterym se aktivuje v clientu napr. v masce ucetni knihy leva dolni sub-frame pro zadavani storna - jestlize konkretni data toto vyzaduji.
To je takovy komlikovany pripad. Proto jeden jednodussi.

Opet se hleda SQL prikaz, kterym se v clientu pro konkretne zobrazena data deaktivuje ikonka disketky, znazornujici ukladani dat. Uzivatel tedy opticky vidi, prave zobrazena data nebude moci zmenit. Tuto informaci musi dostat client v okamziku zobrazeni dat.

Abychom to nezdrzovali - takove prikazy samozrejme neexistuji. Takovou funktionalitu musi nekdo realizovat pomoci nejakeho jazyka a tato funtionalita neni zanedbatelna. Proc by se to melo delat v nejakem primitivnim jazyku, ktery je navic svazan s jednou databazi?

Zdá se, že každý mluvíme o něčem úplně jiném. Takže uvedu praktický příklad toho, co jsem měl na mysli. Mám informační systém sportovního svazu, kde se mimo jiné evidují soupisky jednotlivých družstev. Potřebuju-li provést například přestup hráče z jednoho družstva do druhého, mohu to provést tak, že ho škrtnu na jedné soupisce (jeden SQL dotaz) a přidám na druhou (druhý SQL dotaz). Nebo si napíšu proceduru, která dostane jako parametr ID hráče a ID obou družstev a provede obě operace. Rozdíl bude patrný v okamžiku, kdy budu mít více různých klientských rozhraní (HTTPS psané v PHP, Win aplikace napsaná v C++, ...) a kdy rozšířím datový model. Například se rozhodnu, že chci evidovat nejen aktuální stav, ale také historii (mít možnost podívat se, za jaká družstva hráč kdy hrál), případně budu chtít aspoň historii přestupů. Bez procedury to znamená přidat/opravit odpovídající SQL dotazy na všechna místa (ve všech klientských aplikacích), kde k této operaci může dojít. Použiji-li proceduru, opravím pouze tuto jednu proceduru v databázi a klientských aplikací se mnohdy změna nemusí ani dotknout.

Mate pravdu oba :-) Co jste zapomeli je rict si (a mel by to na pocatku vyvoje udelat kazdy) co pro vas DB znamena?

a) je to blboucke uloziste dat schopne si zajistit konzistenci dat

b) nebo je to i uloziste s implementovanou urcitou logikoou

To a) znamena mit nekde to logiku a zajistit jeji vyuzivatelnost ruznyma rozhranima. Todle neni problem pokud mate aplikacni server. Tedy tri vrstvy.

To b) je o dost narocnejsi, protoze musite dokazat rict jakou logiku sverite DB a naopak co uz ne. Je pak dost narocne uhlidat si co je a co neni v DB. Moznym problemem muze byt i vazba na urcitou DB. Urcite je to super reseni pokud zakladem bude DB a tim blbouckym bude client.

Johanne, proc si proboha myslis ze pouzivani SP znamena ze budes programovat UI v SQL? Co to vubec placas do sebe? Ja mam pocit ze absolutne nevis o cem mluvis...

no ja doufam, ze nam vylozis, jak na to jdes ty. Zatim to sem napsal jenom pan Kubecek. Shrnuji jeho vyvody: SP jsou prima, protoze kdyz napr. vezme Qt, tak nebude psat v tomto klientu jednotlive SQL dotazy, nybrz vyvola provadeni procedury ( v jeho prikladu proceduru='uskutecni_prestup' s nekolika parametry. Taktez to udela pres Apache - opet v php nevola jednotlive SQL dotazy ale proceduru.
Tomu rika vylepseni modularity a ma v principu pravdu.

V cem se s panem Kubeckem neshodnu je, ze me by ani ve snu nenapadlo, psat v nejakem clientu SQL prikazy ale ani volani db-procedury. Ja volam v klientu proceduru aplikacniho servru = 'uskutecni_prestup' a proto je pro me schopnost databaze vyvolavat procedury a starat se o jejich spravu bezvyznamna. Krome jineho, modularita existuje jiz davno pred databazemi.

Zjednodusene recene, pan Kubecek zde hovoril o 2-vrstvem modelu, jehoz silenost - totiz prime pouzivani SQL dotazu (obecneji - jakychkoliv db-zavislych dotazu) on vylepsil pouzivanim procedur.

Nynni k jeho prikladu s temi fotbalovymi kluby. Predstavme si, ze ale fotbalovy svaz pozaduje, aby si software ohlidalo , ze hrac jehoz jmeno zacina na A nesmi prestoupit do klubu jehoz nazev zacina na B. Dale se musi ohlidat max. pocet hracu v jednou tymu pod 170 cm a do Sparty nesmi nikdo kdo se jmenuje Kostal. Uvadim tyto nesmysly proto, protoze v nasi praxi jsou takove pozadavky normalni. A najednou se z jednoduche procedury pana Kubecka stanou procedury s mnoha parametry, subprocedury k proceduram a subsubprocedury k ...

Muj priklad s tou ikonkou mel jeste zvyraznit skutecnost, ze v takovych procedurach musi byt samozrejme i zohledneno, jak se chova UI v urcite datove situaci. Tedy v prikladu pana Kubecka se ma realizovat prestup Mohameda Kostala do Sparty. Vime ze je to nepripustne, ale ignoranti z nasich rad by nechali uzivatele vsechno nejdrive zadat, aby mu nakonec rekli ze Kostal do Sparty nesmi. Solidni softwarove firmy to ve svem software sdeli uzivateli predem. Moje zastrena otazka na pana Kubecne vlastne znela, zda by to v tech procedurach take mel?

A ted nam vypravej ty, jak to tak spravne delas.

OK, to vypada rozumne. Nad SP musi byt nejake software, ktere to volani tech procedur ridi. A toto software ridi jeste to vse jine, co jsem z casti nakousl - rikat klientum co je kdy treba zobrazit, transferovat ps->pdf, vytvaret faxy, hovorit s faxovym serverem, s ldap-serverem, s vytiskovym serverem, s mail-servrem, dokumentacnim servrem, info-servrem...

U me by podil software, ktere bych mohl napsat do SP delal tak 10%.

Proc bych mel tech 10% cpat do SP a delat se tak zavislym na jedne databazi. Vsechny databazove prikazy jsou stejne v jedne knihovne - nebo si snad skutecne nekdo myslel, ze se to pise rozesete po cele aplikaci?.

K cemu by mi bylo vyuziti prav pro spousteni procedur, kdyz kazda konkretni uloha sestava z 90% kodu, ktery neni ( a jak zde nahore stoji ani NESMI byt v SP) a z 10% v SP. K cemu to je, ze pro 10% vyuziji sluzeb databaze a pro 90% si to stejne musim ohlidat svymi prostredky.

A to nejdulezitejsi - jak to vypada s delbou prace. Musi se vsichni sejit u jednoho serveru, aby mel kazdy ten spravny stav SP v te jedne databazi. Co kdyz nekdo dela modul/cast software a pouziva jinou databazi? Kdyz mi vysledky sve prace prehraje, tak ja si to otestuji s mymi procedurami?

Ne, v konfiguraci s aplikacnim serverem, ktery je vsem ostatnim nadrazen (db-server je jeden z jeho sluzebniku), nelze SP smysluplne vyuzit.

A proto zde o tom pisi - cilem clanku bylo priblizit ctenarum, ze MYSQL je nyni take plnohodnotna databaze - take protoze ma nyni SP.

Moje tvrzeni je, ze SP jsou k nepotrebe u komlikovanych systemu. A u mene komlikovanych systemu jsou take k nepotrebe, protoze jednoduche systemy jsou prehledne per se. Z oho vyplyva, nepotrebuji je nikde. A ani argumenty zde diskutujicich me nepresvedcily o opaku. Presto vsem za jejich nazory, i kdyz se neshodnem, dekuji.

Otazka zni zda je lepsi mit jednoho (hovadskeho) guru - nebo par normalnich lidi co venuji 80% casu praci a 20% psani dokumentace. Z mych zkusenosti z hlediska dlouhodobeho vyvoje je to druhe jednoznacne efektivnejsi - to prvni se vyplati jen v situaci vyrob a zapomen.

Jestli ma neco vzniknout jsou potreba normalni lidi a guru soucasne. Jedni bez druheho se proste neobejdou i kdyz se vzajemne zdrzuji.