firebird vs. postgres

[Ing. Pavel PaJaSoft Janousek]

	Omlouvam se za promlku, rad bych jeste odpovedel...

"Ing. Miloslav Ponkrác" wrote:
> vadí. Na druhé straně ale musím napsat, že MySQL se v kompatibilitě SQL
> velmi zlepšila.

	To rad slysim, nicmene dalsi inkompatibility pridava a jeste se tim
chlubi... (GRANT/REVOKE, ALTER napr.) a tvrdi, ze je lepsi nez
'konkurence'

> Vězměte to třeba tak, vývojové nástroje jsou většinou dobře připraveny na
> práci s databázemi. Mnohem hůře pracují třeba s LDAP. Datové modelování IMHO

	Ano, s vetou souhlasim. Proc treba postovni produkty komercnich firem
umoznuji pracovat bez problemu s LDAP a ne s databazemi? Inu proto, ze
coby datastorage je LDAP naprosto dostacujici a je to vhodna
technologie. Ostatne, osobne se domnivam, ze vztah X.509 (?) vs. LDAP
vs. SQL je mozno castecne prirovnat k SGML vs. XML vs. HTML (priznavam
vsak, ze HTML je v trochu 'horsi' pozici nez SQL). Relacni modelovani je
na SQL databaze jak vysite, stejne jako adresarove sluzby jsou jak
vysite pro LDAP. A ja se domnivam, ze 99% WWW aplikaci ma charakter
adresarove sluzby daleko vice nez relacni databaze... berte to zaroven
jako mou odpoved na Vasi namitku o existenci 'SQL' vs. LDAP nastroju.

> Nedomnívám se IMHO, že databáze jsou nevhodným prostředkem pro jednoduché
> datové modely.

	Toto je zreme i soucast nabozenstvi, Vas nazor respektuji, lec nesdilim
zcela. Spise si myslim, ze neco z SQL dostal 'ukolem' kazdy student
informatiky, LDAP jsem ani ja na VS nejak nezaznamenal, domnivam se, ze
i z tohoto trochu prameni 'neduvera' v LDAP (ostatne, o TeX, SGML, XML a
jinych technologiich jsem se nedozvedel na VS rovnez nic...), proto se
vesmes cokoli co zavani ukladanim informaci okamzite 'modeluje' pomoci
relaci (SQL databaze nejsou nic jineho nez relace) - je to cloveku
'blizsi' a zrejme je i vice ovlada. To ovsem nic nerika o vhodnosti te
urcite technologie...

> roku, dvou, sám to dobře vím. Ale já už nepátrám po historii. To je jako
> argumentovat tím, že nebudu používat Linux, protože před 10 lety se nedal
> používat a tudíž mě nezajímá. Prostě dnes tady je MySQL v dnešním stavu a
> historii si nechte jako zajímavost.

	Souhlasim, pokud ovsem toto gentlemanske pravidlo bude dorzovat i druha
strana, narazim zejmena na nekorektni vypady ze strany uzivatelu MySQL v
historii i soucasnosti (napr. ohledne rychlosti, ohledne standardu,
ohledne 'uzasnych moznosti' atd.). V techto pripadech se uchyluji i k
historickemu pohledu... - domnivam se, ze MySQL nikdy kvality PostgreSQL
nedosahla, sla jinymi smery, podpora - bindings - ve vsech smyslech
(nejen k programovacim jazykum) - byla vzdy na horsi urovni, lec ne vzdy
to bylo tak videt. Svuj nazor samozrejme nikomu necpu...

> ODBC je a dobré. Zde je mínusem to, že osoba XY má potíže s multiplatformním
> používáním ODBC.

	Ja bych pripomenul jeste neco - pokud se shodneme na tom, ze UnixODBC
nedosahuje kvalit Windowsovskeho konektoru, pak jsme omezeni i
platformou...

> C API je, ale vám se nelíbí, nebo v něm neumíte psát.

	Ani jedna vec neni spravne. C API se mi libi, a dokonce ho i umim...
vite ono je u kazde SQL databaze +- stejne (zakladni rozdeleni na
synchronni / asynchronni deje a pak execute prikazu...:->), pravda
takovy Oracle na to musi mit struktury..:-) - vazne - dokazal byste bez
ESQL (Embedded SQL) psat v Oracle pomoci C API library?

	Jak jsem jiz nekde (nekolikrat) psal, na konketni implementaci
konkretniho produktu jsem pri vyuziti MySQL C API napsal o 60% vice kodu
nez pri pouziti ESQL + PostgreSQL. Chapu, ze ne pro kazdeho, je toto
argument. Ja jej pouzivam pro podporu toho, ze ESQL ma velky vyznam pro
vyvojare...o portovatelnosti taktne pomlcim...

> proto, že jí strašně miluje. Ale nasadím jí tam, kde je MySQL dobrá.

	Souhlas a ja se domnivam, ze tam, kde je MySQL opravdu dobra si
vystacim s daleko jednodussim a ve svem dusledku robustnejsim resenim
pomoci LDAP, ale to je mozna spise o tom nabozenstvi...

> Bohužel maily ohledně této konference po přečtení mažu. Rád zodpovím
> námitky, které mi uvedete, bude-li to z mých zkušeností. Napište, na co mám
> reagovat.

	Dobre, vynecham-li FUD ohledne MySQL vs. PostgreSQL, ktery jsem si
dovolil v tom samem mailu trochu rozebrat, pak bych mel tyto veci:

> jsem prijemne prekvapen, ze jsou stejne rychle jako myisam (byl to jeden
> slozity select, tusim ze jsem o to referoval sem). Jine zkusenosti
> nebo reference nemam, samozrejme jsem precetl oddil v mysql dokumentaci.

        MySQL 3 roky nepouzivam, proto cerpam jen informace z
www.mysql.org a z
www.innodb.com. Ale i to mi celkem postacuje pro podporu nize uvedenych
tvrzeni.

        Prvni co mne zarazi je zpusob definovani InnoDB v MySQL
- proc bych mel coby uzivatel ci administrator definovat veci jako
auto-extending apod. - vzdyt toto vsechno ma delat databaze sama, ona za
behu nejlepe vi, co jak kdy se deje a dle toho se chovat...

        Toto omezeni je silne neprakticke (a navic mi neni jasne, proc
tomu 
tak musi byt - tedy krome omezenosti autoru MySQL):
Both tables have to be InnoDB type and there must be an index where the
foreign key and the referenced key are listed as the first columns.
InnoDB does not auto-create indexes on foreign keys or referenced keys:
you have to create them explicitly. 

Starting from version 3.23.50 you can also associate the ON DELETE
CASCADE or ON DELETE SET NULL clause with the foreign key constraint. 

- docela pozde nemyslite?
- navic chybi uplne zakladni volba a sice odmitnuti delete... - mam k
dispozici pouze DELETE CASCASE a DELETE SET NULL... - to neni ani dle
ANSI SQL92...

Starting from version 3.23.50, InnoDB does not check foreign key
constraints on those foreign key or referenced key values which contain
a NULL column. 

- zde si nejsem jist, zda-li to neodporuje norme

When doing foreign key checks InnoDB sets shared row level locks on
child or parent records it has to look at. InnoDB checks foreign key
constraints immediately: the check is not deferred to transaction
commit. 

- tak a toto je to HLAVNI omezeni a zde tvrdim, ze v tomto stavu je to
pro opravdu rozumnou praci naprosto nepouzitelne... - v podstate je to
to same, jako byste si vsechno hlidali na aplikacni urovni. Jak uz se po
nekolikate opakuji, ne vsechny 'DML operace' lze zapsat pomoci jednoho
automicke DML prikazu... k cemu mi je commit, k cemu jsou ty tzv.
'transakce'? Ne vzdy je mozno po kazdem DML prikazu mit databazi v
konzistentnim stavu, od toho tu jsou transakce a jednotlive ISOLATION 
LEVELy, abych rekl: tak ted zacinam delat ptakoviny, tak ted jsem
skoncil a
makej... a vysledkem je bud a) - jo bastim Ti to, b) ses blbej, nauc se
pracovat poradne... 

- jak jsme v dalsi diskusi rozvedli, tyka se to samozrejme ovladani
kontroly referencni integrity, resp. mist, kde se kontroluje. Vzhledem k
tomu, ze MySQL nicim takovym neoplyva, dovoluji si tvrdit, ze v pripade,
ze modifikaci databaze nejsem schopen popsat (a takove pripady jsem jiz
'vyrobil' v praxi - coz ovsem nevylucuje moznost, ze na vine je spise
nevhodny datovy model) jednim DML prikazem, nemam sanci takovouto
databazi jiz nikdy zmodifikovat k docileni zadaneho efektu...

        Dalsi vytka se tyka zalohovani - pokud jsem to dobre pochopil,
pak
InnoDB databaze se musi zalohovat jinak... to je super pro
administratora, ktery umi administrovat datastor, ale nevi o datovem
modelovani (proc by to mel vedet?) a o strukture databazi uvnitr
datastoru... Tuto vytku jsem mohl smerovat i na PostgreSQL z duvodu LO,
jenze ty tam byly z historickeho hlediska (a nyni se vesmes jiz
nepouzivaji), navic uz to neni pravda, a co hlavne neimplementuji se
tyto veci takto blbe v dnesni dobe...

	--- toto je konec vytek k InnoDB ---

> I kdybych neznal MySQL, dobře jsem si všiml v argumentacích tendence, že
> fakta jsou podána  tak, aby to pro MySQL vyznělo co nejnevýhodněji. To
> samotné mi nezní věrohodně.

	Ne, moje argumentace se spise trefuje do mist, kde se citi MySQL
uzivatele silni a tvrdi, jak to maji promakane a mne se to z pohledu
vyvojare, ktery pouziva(l) jine datastory jevi pomerne radikalne
jinak...

> Když znám MySQL, tak ne všechny argumenty byly vůbec pravdivé. MySQL má také
> své obrovské nevýhody, i výhody.

	Ja rad svuj nazor poupravim, na zakladne faktu ovsem, ne domnenek.
Zajimalo by mne proto, ktere me argumenty v teto diskusi byly
nepravdive, pripadne (coz rovnez nevylucuji) nejsou JIZ pravdive,
protoze vyvoj pokrocil. Zatim jsem zaznamenal pouze, ze KONECNE existuje
JDBC driver pro MySQL, o kterem jsem skutecne nevedel.

> Mimochodem, zajímavé je, že většinou první argument, který se vytáhne proti
> MySQL je prakticky na 100% vždy nepravdivý. Stejně tak to bylo i v příspěvku
> od "Ing. Pavel PaJaSoft Janousek".

	Jaky vyrok nebyl pravdivy? Ze MySQL neni ACID compliant, vyjma InnoDB a
jeste kteresi tabulky? Ja tuto informaci posleze nacerpal i z
www.mysql.org, tak nevim v cem jsem argumentoval spatne ci co jsem
spatne pochopil?

> Kdykoli se diskutuje o PostgreSQL, tak se vytáhne argument, že MySQL je na
> houby. V tomto vlákně to například udělal první "Ing. Pavel PaJaSoft
> Janousek". Přestože, že o MySQL nebyla vůbec řeč, a přestože se na MySQL
> nikdo neptal.

	Ne, ja jsem reagoval na zjistene ACID (in)compliant...:-) - a jak si na
strance Software602 muzete dole precist, je to dost padny argument pro
lidi, kteri maji rozhodovaci pravomoce...

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------