Názory k článku Letmý pohled na Alfu MySQL 5.0 z pohledu postgresisty

Az to dokoncia, to bude teda migracii z Oracle na MySQL :-)

Ano ano, uz to ma 2% funkcionality a 3% accessibility Oracle, jen tak dal. :-) Jinak jsem ted koukal na list funkci a pokud tam bude slapat vse co se pise, tak to bude mit slusnou podmnozinu funkcionality co mel Oracle 7 (rollout 1993), i kdyz stale chybi par veci, ktere uz byly v Oracle 6 (rollout 1989). Takze je to jenom 11 respektive 15 let zpozdeni. ;-)

Hej ale uvedom si kedy zacal vyvoj Oracle a ake prachy boli za tym!!! Vyvoj Postgresu zacal tiez omnoho skorej ako vyvoj MySQL.

Mozna zapominate na tu drobnost, ze vetsina lidi funkce z Oracle vubec nevyuzije. Napriklad jsem videl stavene webove stranky na Oracle databazi a to mi prijde naprosto zbytecne.

Kdyz treba stavite web, delate statistickou databazi zakazniku apod. - pro co je MySQL urcena pouzijte tyto prikazy: INSER..., SELECT...FROM..WHERE..sort by...

Vic vcelku nepotrebujete. U hodne sluzeb jde vlastne jen o rychlou databazi, kam muzete nahazet milion zaznamu a pak si nechat podle nejakeho klice vyjet deset serazenych. V tomhle je MySQL fakt nejlepsi, protoze je desne rychla a levna. Na nektere ucely ji pry pouzivaj i v NASA.

Jedine co mi na ni ohromne vadi jsou slozite zalohy. Nemuzu proste pres nejakou free utilitu zadat uzivatelske jmeno a heslo, stisknout Backup a dostat jeden soubor a aktualnim stavem databaze. Celkova administrace MySQL je ostatne trosku slozitejsi, ale u nenarocnych projektu to staci.

Patrně nejsnazší je zazipovat celý adresář s tabulkami. Kdyz se neco pokazí, stačí přepsat soubor dané databáze aktuální zálohou a jsme doma.

Ale na to se nesmi do DB zapisovat. Dobry je na to prikaz "flush tables with read lock", ktery flushne tabulky na disk a nedovoli do nich zapsat, dokud se neukonci spojeni, nebo se tabulky neodemknou ("unlock tables").

$ mysqldump -u user -pheslo --add-drop-table jmeno_databaze [ nazvy tabulek ] > soubor
a je to i s kompresí

A když k tomu přidám trochu skriptování, tak to mám úplně jednoduché:
$ mysqldumpcopy.sh nazev_databaze_nebo_all
a za chvíli mám (dokonce na jiném stroji) nazev_databaze.bz2 archiv a předchozí verzi přejmenovanou na nazev_databaze-1.bz2.1

Malá oprava: odmyslete si "a je to i s kompresí", nebo si opravte na mysqldump ..... | bzip2 > soubor

co je špatné na mysqldump ?

vnorene selecty uz umela psql 4.1 (taky je taky alfa resp. apon byla, kdyz jsem ji testoval, ale byla docela nestabilni). A co se tyce te svedstiny - viz http://www.mysql.com/doc/en/Charset-MySQL.html. Stimto mela mysql vzdy problemy, ale neni problem to v konfiguraku zmenit.

problem to nebude, ale od ceho mam locales.

Jak to myslite, ze "Příkaz set nemůže být součástí sql výrazu"?
ja jej pouzivam (pres JDBC) pro definici pouziteho schematu:
stmt = conn.createStatement();
stmt.execute("set search_path = nejake_schema");
stmt.close();
...
stmt = conn.createStatement(); // na stejnem spojeni, samozrejme
stmt.execute("insert into tabulka ...");
a finguje jak ma na nekde jinde (zde vyse) definovanem schematu.

Takze - spatne jsem pochopil Vasi poznamku nebo se jedna o cosi co funguje nedopatrenim a bude odstraneno?

Vyjadril jsem se nepresne. Melo byt psql prikaz set, tj \set. Jde o to, ze v PostgreSQL si nemuzete definovat vlastni promenne v SQL prikazu SET, ktere by se pak mohly uplatnit v dalsich SQL prikazech. K tomu uz musim pouzit programovaci jazyk, treba PL/pgSQL.

Vzhledem k tomu, ze jsem na PostgreSQL vyrustal hodne let (uz tomu bude za chvili 10), dovolim si opravit nekolik nepresnosti a doplneni par postrehu za mne:

- psql pouziva readline - co autorovi clanku chybi po strance pohodli prikazoveho radku?

- parametrizovane dotazy umi PgSQL uz hoooodne davno, v podstate od doby, co se objevil nastroj ECPG, coz neni nic jineho nez Pro*C ala Oracle a obdobne nastroje v kazde rozumne databazi (MySQl, abych nehanil marne, protoze jsem ho uz nekolik let nehledal, ale o nicem takovem v podstate neuvazoval, vystaci si s libmysql, dost ubohe). Ano, mluvim o Embedded SQL, coz je presne misto, kde maji parametrizovane dotazy byt (kdyz uz ne ve stored procedurach - tedy v plSQL)... SQL nic takoveho neobsahuje, dovolim si pripomenout, ze SQL je nadmnozina techto tri jazyku: DDL, DML, DQL (uz jsem to psal mockrat)

- nevim proc by se na "urovni psql" mely implementovat takove zhyralosti jako cykly apod. - nedelejme z konzoloveho nastroje neco, cim nema byt... - copak isql (Sybase), oraclovsky cmd line atd. ma takoveho nesmysly implementovany? Kdyz uz po tom tak touzite, doporucuji Vasi pozornosti nastroj, ktery se jmenuje pgbash pgsh ci jak to je - proste Shell + PostgreSQL - nevim presne nazev. Treba ve zminenem ESQL si klidne SETy provadim dle libosti...

- jako vzor PostgreSQL bych videl spise Informix nez Oracle, a to nejen v historii... On totiz Oracle zase tak moc veci "neprinesl", ale spise pouzil.

- Stored procedury jsou krasne, ale - pouzivaji se hlavne PRO URYCHLENI nejake cinnosti (oproti treba JDBC), na zpracovani DML - tedy triggery apod., takze vyvojare jeste ceka podstatny kus cesty. V tuto chvili mi to pripada jako marketingova fajfka - "mame"

- vycitani nemoznosti dynamicke kompilace myslim neni fer - stored procedury jsou prave elementy, ktere se maji jednou zkompilovat a pak pouzivat, nikoli kompilovat "dynamicky" - copak je problem tu chybejici dynamicnost realizovat pres vstupni parametry?


Dekuji za clanek, utvrdil jste mne, ze o MySQL stale nemusim zavadit:-) - pripadlo mi vsak nefer "vycitat" PostgreSQL nejake super (IMHO hloupe) vlastnosti MySQL... - nejsem nestranny, porovnavam vsak z pohledu "velkych" databazi, nikoli pouze z uhlu PostgreSQL.

Na to, ze v Cechach propaguju prave PostgreSQL, tak se neda predpokladat, ze bych PostgreSQL nejak hanil, ze :->. Viz web: postgresql.ok.cz, ktery udrzuji.

(v pohodlí práce s příkazovou řádkou má stále databáze s delfínkem co dohánět), tj. MySQL je na tom hur. Obe databaze pouzivaji readline, MySQL5 ma autocomplete prvnich slov prikazu. PostreSQL podstatne inteligentnejsi, tj. vcetne nazvu tabulek, sloupcu, atd.

Parametrizovane dotazy, mel jsem na mysli spis funkcionalitu, kterou mohu bezne pouzit, aniz bych musel neco programovat. Ala Prepare a Execute. PostgreSQL nema podporu uzivatelskych session promennych, vyjma jakesi podpory v psql.

Proc by se psql mohlo umet konstrukce: vetveni a cykly. Protoze ne kazdy ma pgbash nainstalovany. hrozne rad bych mel v psql moznost poustet treba procedury v PL/pgSQL lokalne. Zjednodusi se tim napriklad generovani inicializacnich skriptu, parametrizace, a ja nevim co dalsiho. Samosebou, ze to tam nemusi byt. Mohu pouzit Perl, Python, ECPG, cokoliv jineho. Nevidim duvod, proc by to tam byt ale nemelo - navic jsem si to nevymyslel.

Co treba pouziti SP pro servisni zasahy, monitorovani, kontrola dat, manipulace s daty, atd. Mohu si napsat C program, kod SP je ale jednodussi a prehlednejsi (alespon pro mne) (je v ToDo PostgreSQL).

Provadeni kodu v PL/pgSQL je velice rychle. Problem nastane v okamziku pouzivani docasnych tabulek. Problem to je - kod je pak dost necitelny, a i sami vyvojari to chapou jako problem (opet ToDo PostgreSQL).

V clanku jsem vubec nechtel vynaset super vlastnosti MySQL, naopak chtel jsem si vyzkouset co je na tech oslavnych odach (ale MySQL miri do podnikove sfery) pravda. Zaver je ten, ze PostgreSQL je nekde jinde - jak resenim, tak cilema, ale o MySQL se neda rict, ze se o ni neda ani zavadit. Vyvojari udelali hodne, jak s priblizenim norme, tak ve funkcionalite. A maji vlastni nazor jak to delat. Vic jsem netvrdil a ani bych si nedovolil tvrdit. Volba softu by mela zalezet na ucelu, znalostech programatora, uzivatelu, financich, fy. specifikam. Pro MySQL se prostor urcite najde (taky mi vadi "naburela reklama" MySQL AB). Napriklad moznost prilinkovat MySQL k vlastni aplikaci bude pro hodne lidi zajimava. Tohle PostgreSQL nebude umet.

Mně tedy řádkové mysql normálně doplňuje jména tabulek a sloupců. Pokud to máte vypnutné, zkuste \#.

dik za radu, psal jsem, ze MySQL normalne nepouzivam :->

Vyjadrim se k SP - to ze sou rychlejsi je spis side effect. Pouzivaj se k nekolika vecem:

* Bezpecnost. Zadnej login s vyjimkou admina nemuze vic nez spoustit urcity SP. To ti dava kontrolu nad tim co kdo muze.

* Abstrakce. Pokud zmenim strukturu dat (treba prejmenuju sloupec nebo rozdelim tabulku na dve) tak v pripade SPs jen prepisu SP, kod co ji pouziva o tom nebude ani vedet. Pokud bych pouzival adhoc dotazy tak bych musel do vsech produktu co dany objekt pouzivaj a prepisovat (a prelozit, otestovat, rozdistribuovat a tak dal).

Ok, vic me nenapada, ale tyhle dva duvody maj za nasledek treba to ze muj kod uz zadny inline SQL nepouziva, uplne vsechny akce s databazi jdou pres SP.

A jako vzdycky - na nejakou osobni stranku kde mam v DB seznam mych vyplodu je to putna...

MySQL ma jednu vyhodu oproti Postgresu, da sa pouzit aj na Windows. Nie ze by Postrgres neslo, ale je to hruuza..

Docasne, dost intenzivne se na tom pracuje. 7.5 bude nativni na NT, XP.
http://momjian.postgresql.org/main/writings/pgsql/win32.html

Existuji dve komercni varianty PostgreSQL nativne bezici pod win viz http://postgresql.ok.cz

Možná bych měl říct, že MySQL je použitelná i na Windows 95/98/ME a je zde velmi nenáročná na prostředky počítače.

Chtěl jste snad říct, že dokáže plně využít prostředky počítače. Nebo snad chcete tvrdit, že je lepší mít výsledek za 10min při 30% vytížení CPU než je mít za 1min při 100% vytížení CPU?

Sorry, přehlédl jsem dvě písmenka: n a e :-)

To ovšem třeba Firebird také.

Asi bych se s pany od MySQL v pohledu na nektere veci neshodl, ale nutno uznat, ze je to dost velky pokrok a ze na tom opravdu delaj. IMHO to do budoucna mezi PosrgreSQL/MySQL/Firebird zajimave:-) A je to tak dobre.

Mimochodem, když už tu byl zmíněn Firebird, třeba se sem koukne někdo znalý: existuje ve FB 1.5 nějaká možnost, jak docílit u textových sloupců v kódování UNICODE_FSS českého case-insensitive třídění a vyhledávání přes operátor LIKE? Včera jsem strávil dvě hodiny s Googlem a našel jsem pouze radu pro účely case insensitive hledání, která zněla "vytvořit další sloupec, kam by se ukládal tentýž řetězec převedený na velké znaky". A jak česky třídit bez převedení z řetězce v unicode na národní kódování, to jsem už neobjevil vůbec...:-(

podla mojich vedomosti je to momentalne "mission impossible". smiem vediet preco unicode a cestina ?

Protože se v daných textech občas vyskytnou i nečeské znaky. Už jsem to jednou řešil, tehdy jsem zaplaťpánbůh nepotřeboval třídit a pro hledání jsem si vystačil s operátorem CONTAINING, který je case insensitive. Bohužel to teď neplatí...:-(

Jenom mala noticka, jak tu nekdo srovnaval Oracle a MySQL. Myslim ze to neni fer.

Nas informacni system, ktery administruji, bezi na Oracle 8i, ale data ktera maji byt dynamicky k dispozici na webu se kazdou pulnoc prelivaji (aktualnost dat neni klicova) do MySQL. Neznam zadnou jinou databazi ktera ja __TAKHLE__ rychla na jednoduche selecty (rikejme tomu cena "pomer/vykon"). Rekl bych to asi takhle : "kazdemu co jeho jest" :)

Prominte, ale 'dynamicka data' prelevana o pulnoci??

Pochopil jsem to tak, ze se v noci z velkeho a tezkopadneho Oraclu presypou data do jednoduche db struktury bezici pod mysql, ze ktere se pak dynamicky v pripade potreby tahaji udaje (protoze je to v tom pripade rychlejsi)...
Co je na tom nepochopitelneho?

Presne tak :) Dekuji za osvetleni, nejspise jsem to nenapsal tak jasne jak jsem chtel :)

Nehlede na to ze behem toho "prelivani" se s temi daty jeste deji veeeelkaaa kouzla ;)

Cau,mam dotaz.... umi pgsql replikaci?

Pokud si nestahnete upravene zdrojaky tak ne. Opatchovana umi nad spreadem. Nezkousel jsem, nevidel jsem. Kdyby to nekdo chtel vyzkouset, rad se o tom dozvim.

http://gborg.postgresql.org/project/pgreplication/projdisplay.php

a pak jsou jeste dalsi
http://jeremy.zawodny.com/blog/archives/000846.html
http://techdocs.postgresql.org/oresources.php

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.

Zaujimalo by ma ako je to s previazanostou vyvoja MySQL 5 a MaxDB, nakolko MaxDB alias SAP DB obsahuje enterprise vlastnosti a IMHO dosahuje kvality Oracle 7.
Som velmi zvedavy ci MySQL a MaxDB splynu do jedneho produktu, alebo to budu 2 nezavisle produkty, ale potom velmi dobre nechapem snahu zaclenovat urcitu funkcionalitu do MySQL, lebo tym padom si vytvaraju sami sebe konkurenciu v podobe 2 produktov.

A co je na tom k nepochopení? Jaká konkurence, firmě MySQL AB je přece jedno, jestli si pořídíte první, nebo druhý produkt, inkasovat bude tak jako tak.

Naopak MaxDB pro formu znamená možnost proniknout do jiného seh¨gmentu trhu, kde předtím nemohla nic nabídnout.

Navíc pro firmu je důležité neztratit zákazníky pro MySQL db, protože přeci jen je to věhlasná databáze, a nejlepší reklama.

zdravim,
nedavam teto mysql databasi zrovna moc budoucnost. radeji jsem od ni utekl.
jeji vyvoj mi pripada, jako kdyz chcete ze spatne a nestandartne postaveneho auta postavit luxusni a komfortni vuz.
mozna je to dobre na jednoduche weby do 10 tabulek ci na database, kde se hodne selectuje a je treba rychlost. ale na neco serioznejsiho bych to nedal.
jednou za cas se podivam co se deje u teto database noveho, ale tim to konci.
mozna pisu ostrym tonem. ale nedivte se mi. pred chvili jsem dokoncil kus perloveho skriptu na konversi sql dumpu mysql, abych mohl data dostat zpet do mysql database.a dneska jeste budu pokracovat pri mych nevelkych znalostech perlu.
a neskutecne se tesim, az zase napisu psql jmeno_database.
ale abych jenom nehanil, tak jedna vec me na postgresu ted chybela oproti mysql. a to pridavani grantu na celou databasi a ne jenom na jednotlive tabulky.
ale tak ci tak, tyto dve database nejde srovnavat.
bye goldenfish

S tou posledni vetou mate uplnou pravdu. Take si to myslim - jen se neshodnem s tim zacatkem. jak mysql tak psql maji svuj cilovy segment na ktere jsou idealni. PSQL nikdy nebude tak rychle jak MySQL, MySQL pravdepodobne nikdy nebude umet vse to co PSQL - ale ma to sve duvody ktere u mysql stoji jiz od jejiho vzniku.

Tu treti vetu bych opravil spis na 'vyvoj pripada jak kdyby se nekdo z rychleho vozu snazil delat univerzalni vozidlo'. Dokud bude mysql tak rychle jako je ted na trivialni operace, rozhodne nezanikne.

da se rici, ze s posledni vetou ohledne vyvoje mysql s vami z vetsiny souhlasim.