firebird vs. postgres

[Ing. Miloslav Ponkrác]

MP>vadí. Na druhé straně ale musím napsat, že MySQL se v kompatibilitě
MP>SQL velmi zlepšila.

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


Je celkem běžným jevem přidávat rozšíření. U velmi mnoha programů to tak je.

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

PJ>adresarove sluzby daleko vice nez relacni databaze... berte to zaroven
PJ>jako mou odpoved na Vasi namitku o existenci 'SQL' vs. LDAP nastroju.


Uzavřeme debatu LDAP versus SQL, že:

1) konkrétně se lze bavit pouze nad konrétním projektem

2) nechme každého vybrat podle jeho priorit

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

PJ>Toto je zreme i soucast nabozenstvi, Vas nazor respektuji, lec nesdilim

Byl byste dobrým tiskovým mluvčím. Myslím, že bychom se mohli bavit nad
konrétními argumenty. Mohu každý Váš názor, který nesdílím prohlásit za
náboženství.

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

Ani to, jestli se něco učíme na VŠ nic neříká o vhodnosti té, či oné
technologie. Nebo ano?


A znovu musím napsat o vhodnosti LDAP a SQL lze v zásadě hovořit pouze nad
určitým projektem.

Ano, jsou technologie, které jsem si pro sebe oblíbil (SQL, XML), a
technologie, které jsem si pro sebe škrtnul (třeba TeX). Ale je to jen moje
volba, není konečná a mohu kdykoli změnit názor.

MP>argumentovat tím, že nebudu používat Linux, protože před 10 lety se nedal
MP>používat a tudíž mě nezajímá. Prostě dnes tady je MySQL v dnešním stavu a
MP>historii si nechte jako zajímavost.

PJ>Souhlasim, pokud ovsem toto gentlemanske pravidlo bude dorzovat i druha
PJ>strana, narazim zejmena na nekorektni vypady ze strany uzivatelu MySQL v
PJ>historii i soucasnosti (napr. ohledne rychlosti, ohledne standardu,
PJ>ohledne 'uzasnych moznosti' atd.). V techto pripadech se uchyluji i k
PJ>historickemu pohledu... - domnivam se, ze MySQL nikdy kvality PostgreSQL

Dodržujme tedy gentlemanské pravidlo. Ode mě se Vám tohoto výpadu nikdy
nedostalo. Navíc ctím to, že PostreSQL pořádně neznám, a jak vidíte,
nehodnotím jej. Mluvím pouze o MYSQL, jak ji znám, nikoli, co jsem o ní
pouze četl.

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

A závěr? Pokud aplikace je psaná pro Windows, a nehodlám jí portovat, vadí
to? Myslíte, že naprosto každá aplikace je multiplatformní? Většina apliakcí
nikdy nepřekročí jednu platformu.

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

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

Točíme se dokola. Vy jste si stěžoval na C API v MySQL. Po mé oponentuře
jste napsal, že se Vám nelíbí. Proboha, pište si v čem chcete! Já jsem
nepsal, že nutně musím všechno napsat v C API. Já volím prostředky podle
potřeb. A někdy třeba to C API.

Řekněme to takto, třeba bych dokázal psát v C API, ale otázkou je, zda to má
smysl. Stačí?

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

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

Shodněme se na tom, že si každý použijeme to své. Každé řešení má své plusy
a mínusy. A hlavně, záleží na konrétním projektu. Celá argumentace je takto
na vodě.

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


Odpovím v dalším mailu na několik zde vynechaných pasáží.

PJ>Dalsi vytka se tyka zalohovani - pokud jsem to dobre pochopil,
PJ>pak InnoDB databaze se musi zalohovat jinak... to je super pro
PJ>administratora, ktery umi administrovat datastor, ale nevi o
PJ>datovem modelovani (proc by to mel vedet?) a o strukture databazi

Bez problémů můžete zálohovat pomocí utility mysqldump a obnovit pomocí
mysql. Velice snadno a jakýkoli typ tabulek.

Jinak samozřejmě zazálohujete i tak, že zkopírujete datový prostor a
konfiguraci.

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

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

Buďme upřímní, co Vám tvrdím já? Pokud si přečtete zpětně mé maily, tak
rozhodně netvrdím, že MySQL je nejlepší, jediná, atd. A to i tam, kde si
argumentací s Vámi "uškodím". Uškodím v uvozovkách, protože cílem není
vychválit MySQL, ale napsat, kde jsou její silné a slabé stránky.

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


Máte právo na jakýkoli názor.

O pravdivosti, či nepravdivosti Vašich argumentů na MySQL se již nebudu
opakovat, můžete si celé vlákno diskuse snadno přečíst znovu. Reagoval jsem
prakticky obratem.

Mimochodem, slovy "konečně již existuje" opět upozorňujete na minulost.

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


Hledáte mouchy. U MySQL si prostě můžete zvolit, zda chcete používat
transakce, a jaké volbou druhu tabulky. To je celé. Prostě ACID lze
"vypnout".

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

Jen jednu radu. Řiďte se podle recenzí. To myslím ironicky. Ve firmě, kde
pracuji, jsme použili jeden skvělý vývojový přenositelný nástroj od jedné
renomované firmy. Mimo jiné dělají i databáze a názvy jejich produktů
začínají anglickým slovem, které znamená "výkonný". Skvělé recenze, pouze
skvělé recenze, i nezávislé, ale v praxi totální propadák. Samotný nástroj
padal jak hrušky, jinak se choval v debug režimu, jinak za normálního běhu.
Občas třeba u objektů zapomněl zavolat konstruktor, při překlepu v programu
se zhroutilo vývojové prostředí atd.. Od té doby věřím jen tomu, co si
osahám.

Jinak samozřejmě k ACID, komentuji o pár odstavců výše.

S pozdravem

Miloslav Ponkrác