Vlákno názorů k článku MySQL vs PostgreSQL vs Firebird od marx - Je síce pekné, že FB často dosahuje slušné...

  • Článek je starý, nové názory již nelze přidávat.
  • 25. 10. 2005 1:23

    marx (neregistrovaný)
    Je síce pekné, že FB často dosahuje slušné rýchlosti. Ale priznám sa, že by som sa radšej poobzeral po niečom inom. FB je síce viac-menej prepísaný InterBase, ale hlavne pri skutočnom využívaní narazíte na viacero problémov. Základnou chybou je brutálny nedostatok informácií pre programátora (napr. k C API) a spolieha sa na dokumentáciu k InterBase, na čom by samozrejme nebol nič tak hrozné, keby sa kde-tu niektoré veci chovali 'o kúsok' inak. V mailing listoch sa toho príliš nedozviete, pretože väčšina ľudí používa niečo postavené nad týmto API (takže vám zostávajú len tvorcovia API pre PHP, Perl, C++, ...). O problémoch pri práci s BLOBmi, či nikdy nekončiacimi memory-leakmi (bežne vám po commitnutí tranzakcie ostáva v pamäti zopár mega, až kým sa od DB neodpojíte; dá sa dosiahnuť žravosť cez 4MB/s :) ).
  • 25. 10. 2005 2:07

    Almad (neregistrovaný)
    Protože s Firebirdem dělám hodně, investoval jsem 3000 do Firebird DevCD a musím říct, že od té doby si na nedostatek dokumentace nemůžu stěžovat.

    Problémy s memory-leakmi a BLOBy by mě zajímal, nemáte nějaké podrobnosti?
  • 25. 10. 2005 3:26

    agent (neregistrovaný)
    A to jako s každou novou verzí Firebirdu dáte 3000 jenom proto, abyste měl aktuální dokumentaci?
  • 25. 10. 2005 10:17

    Pavel Císař
    Almad mluvi o Developer CD od nas (IBPhoenix). Uz par let jsou na nem e-knihy Using Firebird a Firebird Reference (mimo jine, prubezne rozsirovane specializovane dokumentace pro "pokrocile"). Dokoncuje se Firebird API Guide. S novou verzi FB neni treba kupovat nove CD, protoze rozdily jsou popsane v Release Notes dane verze. BTW, na CD je samozrejme vic nez jen dokumentace.

    Co se obecne moc nevi je, ze dokumentace produkovana IBPhoenixem je s drobnym zpozdenim (cca 2 roky, nejak musime kompenzovat nemale naklady na vytvoreni) uvolnovana Dokumentacnimu projektu Firebirdu (viz web projektu Firebird), a zminovane dve prirucky jiz byly projektu poskytnuty. Bohuzel je to spousta textu, a nejakou dobu jim potrva, nez si to prevedou do XML (pokud si dobre vzpominam, ted je hotovo cca 80%) ktery pouzivaji. Pokud chcete co nejdrive volne dostupne e-knihy o Firebirdu, doporucuji jim trochu pichnout ,-)

    Jinak jsou k dispozici i tistene knihy. Ta co vysla v cestine u Computer Pressu pokryva Firebird 1.0 a 1.5 (nemluve o IB 6.0 - 7.0), vcetne rozdilu a kompletniho prehledu prikazu. Za cca 450.- penez to pro nasince vyjde docela levne. Pak je k dispozici i naprosto skvela THE Firebird Book v anglictine vydana APressem (cca 1000 stran), a ktera je cela jen o Firebirdu. Jeji jedina nevyhoda je absence prehledu SQL prikazu.
  • 25. 10. 2005 12:06

    Miloslav Ponkrác (neregistrovaný)
    Blahopřeji vám k vaší činnosti, nicméně si myslím, že ideální situace je taková, kdyby vaše činnost nebyla vůbec potřeba.

    Váš příspěvek mi jen potvrzuje, že Firebird má katastrofální stav dokumentace, a že to tak nejspíše bude i nadále. Dovedu si představit, jak aktuální budou informace, které po dvou letech přijdou Dokumentačnímu projektu Firebirdu, které jsou pak ještě pozdrženy dalšími převody do XML. Nezlobte, ale s tímto opravdu pomáhat nebudu, ač jsem se již na pár projektech podílel. Rád se budu podílet a věnuji určitý svůj čas na tvorbu AKTUÁLNÍ dokumentace, ale určitě nebudu ztrácet čas s dokumenty, jejichž hlavní hodnota je historická.

    Následující věty jsou jenom můj názor. Podle mého Dokumentační projekt Firebirdu jen ztrácí čas. Neměl by tříštit síly na hafo příruček, ale měl by to udělat tak, jak to vidím u dobře zdokumentovaných projektů jako jsou například MySQL, nebo PHP. Ideální je mít JEDEN velký dokument, ve kterém by bylo vše potřebné. Takový jeden dokument by se jednak dobře udržoval aktuální s mnohem menším nasazením lidské práce, než je současný stav. Jednak by se zbytečně neduplikovaly informace a IMHO je to ta nejlepší forma dokumentace, kterou znám.

    Knihu od Computer Pressu jsem měl v ruce. Mohu o ní říci jenom to, že je to skvělá kniha, ale není to nic víc, než úvodní partie do Firebirdu/Interbase.

    Abych se přiznal, pro mě je to pořád začarovaný kruh. Špatná dokumentace k Firebirdu u mě vede k tomu, že jej prostě nepoužívám.
  • 25. 10. 2005 13:36

    Pavel Císař
    Mno, dovolím si nesouhlasit.

    Jednak dokumentace postoupená projektu není nijak zastaralá, jen Reference Guide by potřebovala doplnit o info (o stejně zatím nevydané) verzi 2.0. Vzhledem k zpětné kompatibilitě v podtatě nic nezastarává, pouze se doplňuje.

    Druhak jeden jediný dokument je krajně nepraktický, speciálně v PDF. Kniha Using Firebird má 766 stran, Firebird Reference má 413. Pokud se k tomu přidá Firebird API Guide a nějaké "kapitoly" na speciální témata, tak by se váš "univerzální dokument" vyšplhal na 1500-2000 stránek. A s tím se prostě dělat nedá, ať už by byl v PDF, HTML nebo i na papíře (jen The Firebird Book má přes 1000 stran, tloušťku 7 cm a váží tři kila).

    Volně dostupné dokumentace je hodně, stačí jen chtít ji najít (v podstatě vše je dostupné z našeho a webu projektu). Že není volně dostupná dokumentace přehledně strukturovaná je sice pravda, ale co by jeden za ty peníze nechtěl :-) Tým PostgreSQL měl na tvorbu dokumentace víc času než Firebird, do dvou let bude mít FB taky takovou. A ti co nechtějí čekat si vždycky můžou koupit knihu. O FB jich už vyšlo docela hodně v mnoha jazycích.
  • 25. 10. 2005 14:29

    Miloslav Ponkrác (neregistrovaný)
    Netvrdím, že vaše dokumentace z doby před dvěma lety není použitelná. Jako z nouze ctnost proč ne.

    Formát jednoho dokumentu je praktický i při rozsáhlých projektech.

    Co se týká formátu PDF tak jej považuji za formát vhodný pro tisk, ale naprosto nevhodný jako normální manuál používaný pro praxi. I když je pravda, že se setkávám v mnoha projektech (ať už komerčních, nebo free) s tendencí vydávat dokumentaci v PDF, snažím se vždy sehnat manuál v jakémkoli jiném formátu, než PDF. Skoro cokoli je lepší, než PDF, pokud to mám používat dnes a denně na vyhledávání informací při vývoji nějakého projektu. PDF je ve skutečnosti spíše grafický formát, než dokument.

    Pro praktické používání je daleko vhodnější třeba vhodně indexovaný HTML. Nevím, co Vás vede k názoru, že se takto nedá dělat s rozsáhlými dokumenty. Například dokumentace k Java 1.5 SE v HTML obsahuje 9765 stránek (většina stránek je svým rozsahem na několik tištěných stran) a vůbec nemám pocit, že by to bylo nějak na závadu přehlednosti a pracuje se s tím velice dobře. Požadovanou informaci v tom najdu v okamžiku. Dokumentace k MySQL stylu vše v jednom v HTML formátu také obsahuje velmi mnoho stránek určitě přes tisíckovku a je to velmi dobře použitelné. Dokumentace k PHP je také značně rozsáhlá ve stylu vše v jednom. Prostě běžně prakticky dělám již řadu let s rozsáhlými dokumenty v HTML/CHM podobě, kde rozsah jednoho dokumentu řádově přesahuje to, co mi tu líčíte jako výsledek u Firebirdu a nemohu si to vynachválit. Naopak obrovská řada projektů má jeden dokument, který svým rozsahem značně přesahuje veškerou dostupnou dokumentaci Firebirdu .

    Je jasné, že taková dokumentace není určena k tisknutí na papíře, to dá snad rozum. Argumentovat nějakou knihou je stejné jako vytýkat Microsoftu, že jeho MSDN přesahuje rozsah knihy.

    Ano, volně dostupné dokumentace je dost, jsou tu ale dvě ale. Na to, abyste se seznámil se základními funkcemi Firebirdu vydáte několikanásobek času, než u jiných srovnatelných databází, který strávíte hledáním a dáváním si různých střípků informací dohromady. A to ještě příznivě podpořeno tím, že naštěstí tu máme slušnou příručku od Borlandu k Interbase. Druhé ale je, že se velmi těžko pátrá po dokumentech, které by trochu popisovaly Firebird do hloubky. Byl bych rád, kdybyste mě zejména v tomto bodě přesvědčil o opaku, a já rád vše odvolám.

    Koupení knihy nic neřeší, protože zkrátka rozsah jakékoli knihy může být jenom zlomkem toho, co může být v kvalitní dokumentaci. Kniha je dobrá věc, ale neřeší vše.

    Závěrem podotýkám, že velmi rád přiložím ruku k dílu, pokud Firebird začne dělat dokumentaci ROZUMNÝM způsobem. Mám ale pocit, že je od toho velmi daleko, a že příliš nevěřím tomu, že Firebird bude mít do dvou let taky takovou dokumentaci. Tedy pokud to bude plichtit stejným způsobem jako dosud.

    Aby nedošlo k mýlce, velmi si Vás vážím a velmi si vážím práce, kterou jste na poli Firebirdu/Interbase udělal. Výše uvedené skutečnosti jsou jenom povzdechy nad tím, co jsem zažil při pokusu o hlubší práci s Firebirdem.
  • 25. 10. 2005 19:01

    Pavel Císař

    Nezlobte se, ale pokud říkáte jeden dokument, pak si pod tím představuji jedinou knihu, případně PDF či HTML soubor. Skupinu HTML stranek třeba i zabalených do CHM nepovažuji za dokument. Proto jsem se divil, že se vám nelíbí rozdělení dokumentace FB na dokumentů, protože i skupinu PDF lze prolinkovat do jediného "dokumentu". Mimochodem i PDF umožňuje hypertextové odkazy v rámci dokumentu, a zmíněné dvě knihy toho hodně využívají. Mezi PDF a HTML tedy nemusí být až takový rozdíl, nicméně uznávám, že vytvořit HTML je jednodušší.

    Nicméně Dokumentační projekt Firebirdu používá DocBook, a produkuje tedy jak PDF, tak čistě HTML verze. Bohužel knihy Firebird Reference a Using Firebird jsou ve FrameMakeru, a převést je do DocBook formátu není až taková trivialita. Základní konverze byla sice strojová, ale vyžaduje to drobné manuální korekce. Vzhledem k rozsahu je to vleklá nudná práce, kterou je jen málo kdo ochotný dělat. Jakmile ovšem bude dokončena, budete mít rázem cca 1200 stránkovou dokumentaci k Firebirdu dostupnou ke stažení či brouzdání přímo na webu projektu.

    Ohledně nedostatku dokumentace a její "roztříštěnosti" se bohužel často zapomíná, že:

    a) Napsat dobrou dokumentaci je zdlouhavá práce, která v případě technické dok. vyžaduje navíc jak znalost problematiky, tak i schopnost jasně a srozumitelně psát. Dobrých tvůrců *ucelené* dokumentace je tedy jako šafránu, a prakticky nikdo z nich není ochoten to dělat úplně zadarmo (ne že by se vydávání tech. knih nějak zvlášť vyplatilo, ale lepší něco než nic). Proto např. dokumentace kterou vytváří IBPhoenix jde přednostně na placené Developer CD (verze Subscription je Firebirdí verze MSDN), a je uvolněna až se spožděním.

    b) Dokumentační projekt si nemůže přivlastnit práci jiných, aby mohl vytvořit jediný superhyperdokument, pořád je zde něco jako autorská práva. Proto je dokumentace poněkud "roztříštěná", a člověk musí informace dohledávat z drůzných zdrojů. To nejlepší co zatím můžeme nabídnout je nashromáždit odkazy na nejdůležitější dokumenty na jedno místo. Obecně je za toto místo uznáván web www.ibphoenix.com nebo .cz

    Ano, volně dostupné dokumentace je dost, jsou tu ale dvě ale. Na to, abyste se seznámil se základními funkcemi Firebirdu vydáte několikanásobek času, než u jiných srovnatelných databází, který strávíte hledáním a dáváním si různých střípků informací dohromady.

    Tenhle problém "zatím" řeší knihy tištěné či na Developer CD. Až se dokončí konverze, budou dvě základní knihy dostupné i volně na webu projektu.

    A to ještě příznivě podpořeno tím, že naštěstí tu máme slušnou příručku od Borlandu k Interbase.

    Ta se běžně nedá legálně sehnat, je třeba ji koupit spolu s InterBase. Volně dostupná je pouze dokumentace k IB 6.0, a to jen díky tomu, že nad tím Borland zavírá oči.

    Druhé ale je, že se velmi těžko pátrá po dokumentech, které by trochu popisovaly Firebird do hloubky. Byl bych rád, kdybyste mě zejména v tomto bodě přesvědčil o opaku, a já rád vše odvolám.

    Mno, zrovna některé knihy jdou překvapivě hodně do hloubky, a popisují i témata které jiné dokumenty moc neřeší (funkce optimalizátoru, struktura databáze, vnitřní mechanizmy funkce serveru apod.). Jinak na webu www.ibphoenix.com jich je celá hromada (bohužel ne nijak přehledně strukturovaná, navíc jsem si teď všiml, že na nedávnou sérii článků pro expery od Ann Harrison není odkaz jinde než v news archivu, což napravíme). To vše a mnoho dalších je součástí Firebirdího MSDN. Já vím, že dost toho je to placené, ale dostupné to je, a je to průběžně uvolňováno pro Dokumentační projekt.

    Koupení knihy nic neřeší, protože zkrátka rozsah jakékoli knihy může být jenom zlomkem toho, co může být v kvalitní dokumentaci. Kniha je dobrá věc, ale neřeší vše.

    To je s prominutím pěkná hloupost. Pokud chcete začít dělat např. v C#, nemusíte si přece hned kupovat MSDN, stačí *dobrá* kniha. Ani např. dokumentace k PHP nebo Pythonu neobsahuje "úplně všechno". A i kdyby obsahovala, tak tím spíš se mi vyplatí nějaká dobrá kniha, která mi jasně a přehledně podá to podstatné co potřebuji (sám mám pár knih o PHP a Pythonu, a nikdy jsem investice nelitoval). Z osobní zkušenosti vím, že taková "úplná" dokumentace je dobrá tak leda jako referenční příručka, kde rychle najdu to co hledám, ale musím nejdřív vědět co hledám. Na učení a informace které bych měl o daném tématu znát mě vždy upozornily spíš knihy.

  • 25. 10. 2005 21:48

    Miloslav Ponkrác (neregistrovaný)
    Ano, vaše argumenty jsou vcelku rozumné. Já bych dodal jenom toto:

    1) Napsat dobrou dokumentace chce určitě jak znalosti, tak určitý talent. Přesto si myslím, že model typu dokumentace v PHP tyto nároky podstatně snižuje. Postavíte prostě osnovu dokumentu a různí lidé mohou doplňovat různé části. Nevznikne tak sice geniální dílo, ale dílo dostatečné kvality ano. K takové dokumentaci může přispět poměrně značné množství lidí a vzniká tak jakási databanka znalostí. Takový dokument má po čase značnou hodnotu.

    2) Dobrá dokumentace je schopna ušetřit obrovské množství člověkohodin práce i vlastním vývojářům produktu. Jde to dokonce tak daleko, že třeba v případě MySQL, nebo PHP máte běžně v dokumentaci budoucí plánované vlastnosti. Jinak řečeno taková dokumentace kromě toho, že je víc než aktuální slouží i vlastním vývojářům k orientaci. Je pak daleko snažší se zapojit i do vývoje projektu a i samotný projekt z toho velmi prosperuje.

    Rád bych ještě vysvětlil můj názor na knihy. Problémem je, že existuje jen mizivé procento knih, které jsou pro mě přínosné. Upřímně řečeno, rezignoval jsem na knihy kromě několika málo autorů jako je třeba Jeffrey Richter. Sám jsem se naučil programovat třeba v PHP podle manuálu staženého z www.php.net a myslím si, že to umím docela dobře. Pokud jsem si listoval knihami o PHP v knihkupectví, nenašel jsem žádnou knihu, která by mi byla užitečná. Python jsem se také učil z internetové dokumentace a neměl jsem problémy. C# jsem se také učil na internetu a pozor! Z knihy od Jeffreye Richtera.

    Souhlasím s tím, že když se něco učím, tak musím vědět, co hledám. Jenže zrovna třeba programovací jazyky jsou zrovna plus mínus na jedno brdo. Naučíte se novou syntaxi, pochopíte pár zvláštností nového jazyka, prolistujete si základní knihovny a pak to chce pár příkladů a praxi. Nic, k čemu bych nutně potřeboval knihu. A programovací jazyk ve skutečnosti spíš dělají knihovny, než cokoli jiného a málokterá kniha je tak rozsáhlá aby mohla být i referenční příručkou. Zrovna programovací jazyky se mi mnohem lépe učí bez knihy.
  • 26. 10. 2005 10:37

    Pavel Císař
    Ad 1)
    Dokumentační projekt Firebirdu takhle funguje. Bohužel používají DocBook místo Viki, což značně snižuje počet možných tvůrců dokumentace, protože mezi uživateli FB není mnoho zběhlých uživatelů DocBooku. Že na webu není vidět celá osnova je jejich rozhodnutí, protože většina stránek by zatím byla prázdná, a jenom by to komplikovalo navigaci k dokumentům, co už jsou hotové. Jak skounčí koverze IBP knih do DocBooku, bude kompletní dokumentace na webu, a bude se průběžně doplňovat a korigovat.

    Ad 2)
    Zajímavá myšlenka. Určitě by fungovala při použití Viki, ale pochybuju, že vývojáře donutíme používat DocBook. On je vůbec problém je donutit napsat jakoukoliv dokumentaci. Jinak na dokumentaci plánovaných a vyvíjených věcí je Roadmap, dokumenty přímo u zdrojáků v CVS a Jim Starkey udělal i něco jako Viki v Netfrastructure.

    Co se vašeho názoru na knihy týká, já vám ho neberu, ani vás nepřemlouvám. Ale pokud svůj osobní názor prezentujete jako obecně platný fakt, tak se prostě musím ozvat.
  • 26. 10. 2005 15:06

    Miloslav Ponkrác (neregistrovaný)
    Děkuji za vysvětlení.

    Chápu, že použití DocBooku spoustu lidí odradí. On přeci jenom Firebird je z velké části záležitost Windows a rozchodit na Windows celý fungující systém s DocBook není až tak triviální záležitost. Pokud vím, tak ani na Windows neexistuje žádný balík, který by to lidem ulehčil a nainstaloval vše potřebné. To je dost vysoká překážka přispívání do dokumentace.

    Co se týká mého názoru na knihy, netvrdím, že jde o objektivní názor. Ostatně pro někoho jiného mohou být knihy klidně to pravé. Já jen při koupi většiny knih jsem neustále znovu a znovu zklamáván, ač se občas vyskytnou i knihy, které mají mé vysoké hodnocení. Zjistil jsem, že nejhorší úroveň (z mého pohledu samozřejmě) má většina knih vydávaných Microsoft Pressem.
  • 5. 12. 2005 14:16

    PaJaSoft
    Slusi se dodat, ze soucasti JDK je i veskery komfort okolo te dokumentace... Ano mluvim o vsem okolo JavaDocu...;-) Na stranu druhou vim, ze existuji podobne systemy i pro daleko starsi navrhy a navrhove vzory - treba C/C++.
  • 26. 10. 2005 7:30

    MaReK Olšavský
    Zlatý podporovatel

    Pavle také si dovolím nesouhlasit, ale s Tebou :-) Podle potřeb projektů používám MySQL, PostgreSQL a FirebirdSQL. Poslední jmenovanou zejména díky kvalitnímu propojení s Borlandími vývojovými nástroji.

    Dokumentace FbSQL není v nejoptimálnějším stavu, to je fakt. Pravdou je, že proti PgSQL/MySQL je tento server o mnoho pátků mladší a tudíš je to pochopitelné.

      Co mě u FbSQL chybí? (je to jen malinké zrcadlo toho, co jsem napsal na dbsvete o tom, co se mi libi na PgSQL)
    • má poměrně málo typů a vytváření ekvivalentu serial je trochu \"přes ruku\"
    • Nemožnost použít pro stored procedury jiný jazyk, než vestavěný PL/SQL (zde jasně vede PostgreSQL) i když srovnám-li, co uměl PL/SQL v FbSQL 1 a co umí nyní, je to teď o 200% lepší.

    Líbí se mi existence Embedded verze a to je veliké plus, protože většina malých projktů nepotřebuje plnou instalaci serveru. Líbí se mi učebnice, kterou jsi napsal, byť zcela logicky nemůže pokrývat celou šíři toho, co FbSQL umí a nabízí.

    btw: Doufám, že nevadí, že jsem na tomto serveru zvolil tykání :-)

  • 26. 10. 2005 10:12

    Pavel Císař
    S novými datovými typy nemohu sloužit. Tohle se plánuje až po sloučení Firebirdu a Vulcanem, tedy až po FB 3.0, kdy pro to budou vhodnější podmínky. Nicméně uložené procedury a spouště v jiných jazycích už jsou dostupné v rámci projektu Fyracle (Oracle mode pro Firebird). V poslední verzi Fyracle 0.8.9 je možné na serveru používat vedle PL/SQL Oracle i jazyk Java.
  • 5. 12. 2005 14:21

    PaJaSoft
    Datovy typ serial se Vam bude u PgSQL libit do doby, kdyz na vlastni kuzi poznate, ze datovy typ serial a default nextval('seq') je trochu v praxi neco jineho... (ano, oboji vede na vytvoreni sequence, bohuzel nastavit hodnoty sequence na pozadovane, pokud nevyhovuji defaultni je opravdu porod).

    PS: Mluvim o PgSQL 8.0.X, nikoli starsich verzich.

  • 4. 9. 2006 15:35

    talpa (neregistrovaný)
    ne lepsi je koupit si oracle nebo mssql server za mnohem vyssi castku;-) a mimochodem dokumentace k ms sql serveru take neni zazrak, u fb se mas na koho obratit takovej pavel cisar je fakt guru ktery ti poradi jak muze a nezistne...uzasnej clovek.
  • 25. 10. 2005 12:44

    marx (neregistrovaný)
    Pokúsim sa zhrnúť to, čo si pamätám bez hľadania zdrojákov. Viac info cez mail (marx@linux.sk).

    Takže pracoval som s veľkou databázou, ktorá bola stromovo orientovaná a listami boli súbory uložené v BLOBoch. Rýchlosť práce s BLOBmi klesala úmerne s veľkosťou DB a niektoré funkcie mi vyslovene chýbali (FB spred cca pár mesiacov). Tá rýchlosť bola miestami pod hlboko pod tým, čo by som očakával, ale nakoniec sa to dá zniesť.

    Problém so žraním pamäte DB servera bol vcelku jednoduchý. Po uzavretí tranzakcie sa miesto v pamäti neuvolnilo (prip. znovu nepoužilo) a bolo potrebné spraviť disconnect/connect v dobe, keď nebola otvorená žiadna tranzakcia. V mojom prípade som sa o to snažil po 10+ vykonaných operáciach. Toto inžinierske riešenie funguje a tak ma to prestalo trápiť. Samozrejme, že je možné, že som pozabudol na uvoľnenie niečoho (aj keď si myslím, že skôr nie), ale na druhej strane väčšina mojich výsledkov mala výsledky v jednotkách záznamov, takže by som skôr povedal, že to bolo niečo čo som vidieť ani nemal. Ale ako som písal stačí sa znovu pripojiť a pamäť je v pohode.

    Skúsenosti s JDBC, príp. inými high-level API nemám.
  • 25. 10. 2005 13:41

    Pavel Císař
    Pokud jste používal přímo API Firebirdu, pak je problem jasný: neuvolnil jste statement handle svých příkazů. Ukončení transakce totiž statement handle (i.e. SQL příkazy) neuvolňuje, protože se nejedná o resource transakce, ale spojení k databázi (lze je použít ve více transakcích). Firebird v tomto směru zkrátka funguje jinak než jiné databáze. Toto rozhodně není memory leak.
  • 25. 10. 2005 14:27

    marx (neregistrovaný)
    Tak som sa na to schválne pozrel :) Dokumentáciu k API InterBase som mal preštudované myslím dosť slušne a poctivo som uvoľnoval, čo šlo. Pokiaľ uvoľňovaním statement handle myslíte:
     isc_dsql_free_statement(status_vector, &stmt, DSQL_close); 
    tak vedzte, že toto som robil. Skutočne si myslím, že to bude memory leak. To samozrejme neznamená, že sa vyskytuje všade. Len ja mám na netradičné bugy v programoch jednoducho šťastie.
  • 25. 10. 2005 3:22

    anonymní
    Tak pod to se můžu podepsat. Když jsem si stěžoval na naprostý nedostatek dokumentace k Firebirdu, bylo mi nadáváno. Jediná trochu kompletnější dokumentace je k Interbase a ta samozřejmě ani nemůže odrážet poslední vývoj Firebirdu. Jinak vám zbývá pár střípků rozházených tu tam, tu onde, ale nic kompletního se nedozvíte. Pak musíte s každou ptákovinou otravovat přímo vývojáře Firebirdu a často si nejste jistí, jestli to, co vám provádí zrovna databáze je bug, nebo feature, nebo něco jiného. Pro mě samotného to bylo důvodem k zamítnutí Firebirdu.
  • 25. 10. 2005 7:06

    pkm (neregistrovaný)
    Občas pracuji s IB. FB je mezi free databázema, co se fíčur týče, snad nejnamáklejší ze všech. Rychlost taky evidentně fajn. Ale je to takové "málo zdokumentované" a "málo prověřené" řešení. Když jsem se snažil připojit FB k Monu, narazil jsem na divné problémy s právy (asi chyba Mona, ale stejně) a nebyl jsem schopen k tomu zjistit pořádné informace. No a ty memory-leaky jsme několikrát řešili v práci, no tam má zase díl viny svéhlavý JDBC driver.

    Musím uznat, že výkonové charakteristiky mi vyrazily dech, až mám pocit, že je někde chyba. Postgres je pomalá sračka, když vidí složitější dotaz, vykašle se na optimalizaci a klidně sjede tabulku s milionem záznamů sekvenčně, fuj.
  • 25. 10. 2005 13:46

    Miloslav Ponkrác (neregistrovaný)
    Já osobně bych se taky Firebird příliš neodvážil nasadit. Právě díky jeho "tajemnosti". Jasně, že není problém používat Firebird základním způsobem, ale raději pracuji s databázemi, o kterých vím něco víc.

    Problém je, že jakmile nastane skutečný problém, často nevíte, co je vlastnost databáze, protože podrobnější informace často chybí. A dokud projekt Firebird nezaloží jeden jediný dokument, do kterého se budou doplňovat informace o Firebirdu, tak situace nebude lepší.

    Co se týká výkonových charakteristik Firebirdu, tak na místě autora bych se první ptal, kde je chyba. Netvrdím, že Firebird nemůže být pekelně rychlý, ale ty výsledky jsou opravdu podezřelé a určitě bych se pokusil dopídit, proč jsou takové. Moc jim nevěřím, abych se přiznal.
  • 25. 10. 2005 19:11

    Pavel Císař
    Mistře, nestrašte nám tady lidi nějakou "tajemnou" databází. Firebird je tu pod tím či oním názvem už přes dvacet let. K dispozici je dost knih, dokumentů, školení, komponent, aplikací, veřejná databáze chyb, lidí v konferencích s dloholetou zkušeností i přímo vývojářů kterých se kdokoliv může na cokoliv zeptat, nebo jen tiše sledovat cvrkot, a konečně jsou tu kompletní zdrojáky volně k stažení pro kohokoliv. Firebird tedy rozhodně není žádná "tajemná" databáze pro nikoho, kdo se o ní chce něco dozvědět, nebo vyřešit konkrétní problém.
  • 25. 10. 2005 22:00

    Miloslav Ponkrác (neregistrovaný)
    Myslím, že vám to tak pane Císaři připadá z pohledu člověka, který tomu věnuje spousty času. Moje zkušenosti jsou takové, že k získání stejného množství informací ve srovnání oproti jiným databázím musí člověk u Firebirdu věnovat několikanásobek úsilí, času, případně peněz. Jasně, když za tím tvrdě půjdete a nebudete hledět nalevo, ani napravo, tak nějaké informace nakonec získáte, ale to platí o všem, nejenom u Firebirdu.
  • 26. 10. 2005 12:24

    benzin (neregistrovaný)
    To je hodne subektivni pohled. Take jiste zalezi na tom z jakeho prostredi prichazite (Unix X Windows, C/C++ X Delphi X Java). Ja osobne jsem odchovancem Delphi vyvoj ve FireBirdovi mi nedela sebemensi problemy, kdezto MySQL umi pouzivat jenom na zakladni bazi. Nejsem zvykli pouzivat primo zakladni API pokud to neni nutne, radeji vyuziji komponentu nebo Bean.

    Z teto pozice musim rict, ze FireBird je na tom lepe nez MySQL a jeste vic nez PostgrSQL.

    Verim, ze pri pouziti Cecka muzou nektere veci cinit jiste problemy, ale nesnazte se to zobecnovat.
  • 26. 10. 2005 12:26

    benzin (neregistrovaný)
    To je hodne subektivni pohled. Take jiste zalezi na tom z jakeho prostredi prichazite (Unix X Windows, C/C++ X Delphi X Java). Ja osobne jsem odchovancem Delphi vyvoj ve FireBirdovi mi nedela sebemensi problemy, kdezto MySQL umi pouzivat jenom na zakladni bazi (a to s nim delam daleko dele). Velmi problematicky se mi hleda co vlastne ta ktera verze MySQL umi a jak jsou ty ktere veci implementovany. FK se mi nepodarilo vytvorit doted. Chyba je jiste mezi klavesnici a zidli, protoze proste neumim v dokumentaci MySQL hledat, ale stejne to bude u Vas a FireBirdu.

    Nejsem zvykli pouzivat primo zakladni API pokud to neni nutne, radeji vyuziji komponentu nebo Bean. Z teto pozice musim rict, ze FireBird je na tom lepe nez MySQL a jeste vic nez PostgrSQL.

    Verim, ze pri pouziti Cecka muzou nektere veci cinit jiste problemy, ale nesnazte se to zobecnovat.
  • 26. 10. 2005 0:33

    truba (neregistrovaný)
    Myslite, ze MySQL je mene "tajemna" a vice proverena, kdyz ji kazdy php trouba pouzije pro webove stranky sve vesnice? ;-)
  • 26. 10. 2005 15:32

    Miloslav Ponkrác (neregistrovaný)
    Výborná myšlenka, doufám, že to myslíte ironicky.

    MySQL je rozhodně výborně zdokumentovaná databáze a tvrdím, že jsem ještě neviděl otázku ohledně MySQL ať už položenou tady, nebo na jakémkoli jiném diskusním fóru, na kterou byste nenašel odpověď v základním manuálu MySQL. Ještě se mi někdy nestalo, že bych se potřeboval ohledně MySQL někdy někde někoho na něco ptát. A to jsem dělal s MySQL lecjaké skopičiny a potřeboval jsem znát informace hodně do hloubky. To u jakékoli jiné databáze jsem se snadno dostával do stavu, kdy jsem prostě musel shánět informace i jinde. A upřímně řečeno, Firebird je z tohoto hlediska, tedy z hlediska dokumentace, to nejhorší co jsem zažil. Proto mluvím o "tajemnosti" Firebirdu.

    MySQL je rozhodně i dobře prověřená databáze. Jako databázový server je MySQL nasazena poměrně ve značném počtu kusů a k prověření samozřejmě přispívá i to, že jí každý php trouba použije pro své webové stránky. Já sám osobně ji za prověřenou a spolehlivou považuji, protože po řadě let zkušeností mě z tohoto ohledu nikdy opravdu nezklamala.

    Jiná věc samozřejmě jsou schopnosti MySQL, ty jsou i v MySQL 5.0 dost pozadu za schopnostmi mnoha jiných databází. Když k tomu připočtu i to, že za komerční použití MySQL se musí platit, a IMHO podle mě příliš vysokou částku v poměru ke skutečným schopnostem MySQL, tak mi z toho vychází, že preferuji spíše jiné databáze.
  • 25. 10. 2005 7:21

    Ludvik Roubicek (neregistrovaný)
    Firebird je v Linuxu pomerne stabilni, ale pomala databaze. Nedostatek dokumentace me stval take, ale dalo se to vetsinou prekonat. Jediny vaznejsi problem, ktery jsem mel, se tykal presnosti cisel s pohyblivou radovou carkou v jednom z dialektu SQL. Doloval jsem data a vysledkem bylo, ze 0 > 0 (kvuli nepresnosti v x. radu). Kdyz jsem zmenil podminky, sice to fungovalo, ale pooooomaaaaaluuuuu.
    Zpracovani nekolika tisic faktur pro vytvoreni jejich seznamu (JOIN nekolika tabulek) trvalo v nasazenem ucetnim programu desitky sekund az jednotky minut. A to pri pripojenych pouze 5ti uzivatelich...
    MySQL je vyrazne rychlejsi - testovano v podstate na stejnych datech, pouze v jinem ucelu vyslednych dat. SELECT v MySQL je take intuitivnejsi, zejmena pri seskupovani dat (GROUP BY).
    Testovano v praxi na P4HT 3GHz, 1GB RAM, 2xIDE 120 GB/8MB sw. mirror. Mandrake nabiha v teto konfiguraci do konzole behem ani ne 20s od zapnuti pocitace :)
    Osobne bych na produkcnim serveru MySQL za Firebird nevymenil. Alespon dokud bych se obesel bez ulozenych procedur atd.
    Pokud autor nenasel nastroj pro administraci Firebirdu, bud neumi anglicky nebo se na web Firebirdu ani nepodival. Perfektni, lec jeste nedodelany je FlameRobin.
    BTW: testovat databazi ve Windows a jeste ke vsemu na 20GB pomalem disku, je amaterismus. Zajiste takto pobezi vetsina databazi, ze? A priste co? Budou se testovat databaze pod VMware??? Prosil bych seriozni srovnani, tj. na stroji, ktery se pro provoz databaze hodi vice (nemusi jit nutne o xeon), v systemu, ktery se pro server hodi vice (Linux v konzoli, MS Win SERVER, Unix), s testy, ktere alespon priblizne simuluji bezne nasazeni, tj. vkladani, nacitani, odstranovani v nahodnem poradi, spojovani tabulek, seskupovani dat...
    Clanek nema valnou informacni hodnotu, je pouze projevem nadseni autora z objeveni Firebirdu.
  • 25. 10. 2005 8:52

    misch (neregistrovaný)
    testovat databazi ve Windows a jeste ke vsemu na 20GB pomalem disku, je amaterismus

    Nerozumím téhle poznámce. Smyslem testu bylo myslím porovnat databáze mezi sebou, a ne vytářet nějaké ABSOLUTNÍ benchmarky. Není jedno, jestli databáze na "20 GB pomalém disku" vrátí výsledek za 10 vteřin (přičemž na lepším serveru by ho vrátila za 2 vteřiny), když měl autor v úmyslu pouze porovnat výsledky různých databází a SELECTů mezi sebou?

  • 25. 10. 2005 17:04

    Ludvik Roubicek (neregistrovaný)
    Jednoduse a strucne: vetsina databazi, u nichz zalezi na vykonu, bezi na unixovych, linuxovych a jinych serverovych systemech. Nehlede na to, ze Firebird pod Linuxem muze bezet jako klasicky server nebo super server (verze CS, SS). To ma docela podstatny vliv na vysledne chovani. Zrovna tak bude databazovy server behat s nejvetsi pravdepodobnosti na procesorech s hyper threadingem, ne-li na viceprocesorovem stroji - zase: jak to bude pri pouziti CS a SS?
    Takze jeste jednou: jestli pobezi rychleji v nejakych desktopovych Windows ta ci ona databaze, je vcelku jedno.
    Pokud budu porovnavat auta, take s nimi nepojedu 50m, ale nekolik kilometru. A take s nimi projedu nejakou tu zatacku, abych vedel, jak se chovaji, a urcite nepojedu 20 km/h a uz vubec ne na dalnici...
  • 25. 10. 2005 10:06

    Jan Sunavec (neregistrovaný)
    Co sa tyka benchmarkou a hardwaru je to dost problem. Testoval som to na slabsom stroji lebo tam viac vyniknu rozdiely medzi platformami. Taketo testy sa daju robit na X hardwarovych konfiguraciach. Jedine co mal test vypovedat, je ze na stroji X, bezia databazi takto..
    Co sa tyka nadsenia z Firebirdu, som skor zastanca PostgreSQL, MYSQL je sice rychla, ale moznosti su dost slabe.
    Dokumentacia Firebirdu je fakt dost zla, ako produkcnu databazu by som to urcite nenasadzoval ani v krajnom pripade. Ten flameRobin som vyskusal ale ako ste sami povedaly, je to nedokoncene..
  • 25. 10. 2005 17:38

    Ludvik Roubicek (neregistrovaný)
    Ja vim, ze to neni jednoduche, ale pro zvyrazneni rozdilu bych pouzil vetsi objem dat. Spise bych to testoval pod Linuxem nebo pod Unixem, popr. jeste pod serverovymi Windows. Proste v nejakem realnem prostredi, s realnou zatezi a realnym objemem dat. Ony se pak jednotlive databaze mohou chovat jinak nez ve vasem pripade. Dtto hardware - testoval bych to alespon na procesoru s HT, protoze nektera databaze ho umi vyuzit lepe, nektera hure a pak to velmi ovlivni porovnavane vysledky. Takze v podobe, jak to bylo provedeno, je toto srovnani pro me nepouzitelne. Zajimave ano, pouzitelne ne.
    Ad FlameRoobin - je sice jeste nedodelany, ale pouzivam ho uz od nejake alpha verze (nepamatuji si presne, ale byla to urcite verze < 0.2) a funguje, pouze jsou postupne doplnovany dalsi funkce. Nedodelany, ale velmi dobre pouzitelny.
    Jako vzdy - pri vyberu databaze je samozrejme potreba vzit v uvahu co umi, co podporuje, jak je v danem pripade rychla, proste k cemu se hodi a k cemu ne. Ale jako podklady k rozhodovani potrebuji jine informace.
  • 25. 10. 2005 7:33

    bez přezdívky
    Nesouhlasim s tvrzenim o BLOBech a memory-leacich. Pouzivame v praci FB 1.5.2 uz od doby jeho relesu (asi rok a pul) a ma samozrejmne sve mouchy, ale jinak bezi perfektne. Pristupujeme na ni pres zakladni C-api a k zadnym memory leakum nedochazi ani k prebytecnemu zrani pameti nedochazi. A to podotykam, ze vyuzivame 95% ze vsech funkci, ktere jsou v API k dispozici (jedine co nepouzivame jsou commit_retaining, ci tak nejak, a souvisejici savepointy (zasveceni urcite vi, o co jde)).

    Prace s BLOBy je sice ponekud komplikovanejsi, ale zato je efektivni a setrna k prenosovemu pasmu pri komunikaci po siti apod.

    Co se tyce spotreby pameti. Ono se po commitnuti transakce musi take uvolnit z pameti statement handler a popr. alokovane XSQLDA struktury (zasveceni opet vi, o cem je rec).

    PS: Pokud pouzivate vlozene procedury (PSQL) tak je vhodne skutecne pristupovat primo na rakdy (resp. na jejich aktualni verzi) pres RDB$DB_KEY identifikator, ktery se vramci jedne aktualni transakce nemeni. Pak je skutecne FB 1.5.2 rychly jako blesk ...
  • 25. 10. 2005 8:21

    Leos Literak (neregistrovaný)
    A jake mate zkusenosti s FB a JDBC? Ze je spatna dokumentace k C API me zajimat nemusi, pokud je bezproblemovy JDBC ovladac a existuje popis SQL dialectu.
  • 25. 10. 2005 20:45

    bez přezdívky
    Já mám jen ty nejlepší. Oslovila mě knížka pana Císaře, od té doby naprosto v pohodě. Zkušenosti mám tedy jen s TYPE4 ovladačema (nebo jak se to ... ty co se připojují přes inet sockety).

    Výhodou je hw nenáročnost Firebirdu. Zajímalo by mě však větší nasazení Java-Firebird (například nějaký web), moje pokusy jestě nic nedokazují.
  • 26. 10. 2005 9:33

    jozef (neregistrovaný)
    Potvrdzujem ze JDBC je v pohode. Bohuzial web nemozem uviest lebo sa jedna o intranet. Aplikacia bola vyvijana na Windows (Tomcat, Struts, iBatis DB Layer), u zakaznika je Linux a PostgreSQL. Nase skusenosti su jednoznacne v prospech Firebirdu, omnoho lepsi vykon. PostgreSQL je nutne pravidelne "vakuovat" lebo vykon zdochyna (chcipa ?). BLOBy nepouzivame, takze nemozem potvrdit ani vyvratit problemy z tejto diskusie. Produkcna PostgreSQL databaza stale narasta lebo sa v nej ukladaju data z vyroby, jej aktualnu velkost mozem zistit ak by bol zaujem.
  • 27. 10. 2005 22:02

    Marian (neregistrovaný)
    Pokiaľ ide o Firebird a JDBC, naposledy, keď som sa tomu venoval (Firebird 1.5.1 a s ním súvisiaci release JDBC drivera) bolo takmer nemožné sa dopátrať informácie, či JDBC driver je thread-safe alebo nie. Druhým vážnym nedostatkom v tom čase bola absencia Linuxovej embedded verzie Firebirdu.