PostgreSQL, alebo Firebird?

On třeba skutečný tazatel nechce platit ani za MS SQL, ani za MySQL s tou jejich přiblblou interpretací GPL. ;-)

On třeba skutečný tazatel nechce platit ani za MS SQL, ani za MySQL s tou jejich přiblblou interpretací GPL. ;-)

prepacte, ale nepochopil som vasu odpoved. nie som "automaticky generator dotazu".

MySQL som sa rozhodol nepouzit preto, lebo po porovnavani (vyhladavani na nete) som usudil, ze sa na moje ucely nehodi. podla toho co som zistil, je vhodna skor na web, ale nie na podnikove databazy. aj ked informacie boli väcsinou starsieho data a bolo napriklad argumentovane tym, ze nema transakcie (co myslim uz ma), ale aj tak sa odporuca pouzit skor pri mensich projektoch.

nemam skusenosti s väcsimi databazovymi nastrojmi (MS SQL a pod.), preto sa mi tazko porovnavaju - to bol dovod, preco som sa pytal tu.

Transakce už má, a i na podnikovou databázi by možná šla použít (záleží asi na podniku ;-)), ale pokud nechcete utrácet za MSSQL, nejspíše nechcete utrácet ani za MySQL. MySQL vyžaduje komerční licencování i v případech, které podle GPL a právníků FSF neporušují licenci, ale podle právníků MySQL ano. Ti zmetci třeba tvrdí, že s GPL verzí MySQL nesmite používat non-GPL klientský software, a to dokonce i v případě, že používáte vlastní klientskou knihovnu (nikoli klientské knihovny od MySQL). Tohle by si nedovolil ani Richard Stallman. ;-) Asi za tím budou prachy, jako vždycky.

Dakujem. S licenciou som si nebol isty, pretoze o MySQL som pocul raz jedno a raz druhe.

Zrovna MySQL má z těhle tří databází nejlépe vyřešenou replikaci, což je podle mě úplně zásadní podmínka pro použití na čemkoliv než "menší projekt". Celé to srovnání web x podniková databáze dost pokulhává, podniková databáze může být klidně jako intranet a kde je potom rozdíl?

Konkrétně informace o transakcích musela být neuvěřitelně starého data, protože MySQL umí transakce na InnoDB tabulkách roky. Pokud i zbytek informací byl podobně aktuální, tak doporučuji zahodit ;-)

"což je podle mě úplně zásadní podmínka pro použití na čemkoliv než "menší projekt"."

Méně zásadní, než stabilita, robustnost, vysoký výkon, snadná údržba? Nevím, co je "menší projekt", je 11 terabajtů "menší projekt"? (viz zde) Nějak se mi nechce věřit, že byste zrovna Vy pracoval na systému, který narazí na meze schopností Firebirdu nebo PostgreSQL. To se podaří jen málo lidem. Možná tak v bankách :-), ale tam stejně používají úplně jiné věci.

Taky nevím co je "menší projekt", zeptejte se původního tazatele, který sem tenhle kouzelný termín přitáhl (protože MySQL není na nic než "menší projekt" vhodné). Zbytek neřeším, na podobném projektu jsem nepracoval... ale to přece není tématem diskuze, snad jenom pokud někdo není "Rejpal" ;-)

"protože MySQL není na nic než "menší projekt" vhodné"

Ale to som netvrdil, aspon nie takto.

"ale to přece není tématem diskuze..."

S tym suhlasim, dakujem za pochopenie.

"Nějak se mi nechce věřit, že byste zrovna Vy pracoval na systému, který narazí na meze schopností Firebirdu nebo PostgreSQL"

Pokial to bolo na mna, tak urcite nie. :) Tak to ani nebolo myslene. Doteraz to boli databazy s maximalne niekolko desiatkami tabuliek (ale mensim poctom zaznamov), alebo jednoduchsie databazy, kde bolo niekolko stotisic (neskor asi aj cez 1 mil.) riadkov. Cize do 2 GB (viac sa u MS Access nedoporucuje).

Z doterajsich prispevkov a odkazov vidim, ze toto nie je pre mna kriterium vyberu, obe riesenia mi pripadaju viac ako postacujuce a kazde ma nejake + a - (co som aj predpokladal ;) ). Skor by som potreboval poradit ohladne toho, co bude pre mna jednoduchsie "rozchodit" - kedze s nimi nemam skusenosti. Uvazujem o Firebird + Python.

Nene, myslel jsem to na toho pán, co razí MySQL kvůli replikaci jako "naprosté nutnosti". :-)

Firebird a Python je výborná kombinace. Pavel Císař, přední český firebirdista, pracoval kdysi (možná ještě pracuje, to nemůžu vědět :-)) v Delphi, ale jestli jsem to pochopil správně, přešel přinejmenším zčásti na Python. Pro Firebird a Python existuje moc pěkná klientská knihovna kinterbasdb, která podporuje prakticky vše, co Firebird klientům nabízí, včetně Services API pro správu serveru z aplikace. Instalace Firebirdu, Pythonu a kinterbasdb ve Windows je bezproblémová věc. Docela užitečnou tenkou nadstavbou nad kinterbasdb, která se neznaží spasit svět skrz ORM, naleznete na stránce http://projects.almad.net/dbclass . Pokud vím, autor dbclass používá Firebird+Python+kinterbasdb+dbclass tenhle SW v provozním nasazení včetně provozu ve Windows.

Jojo, požadavkem je, aby databázový server umožňoval vytvořit master-master failover řešení :-) Zatím jsem nenašel, jak tento požadavek JEDNODUŠE splnit na PostgreSQL nebo Firebirdu. Pokud původní tazatel podobný požadavek nemá, tak může mojí poznámku klidně ignorovat.

"požadavkem je"

Asi jste zapomněl jste na slovíčko "naším". Protože kdyby tu potřebu měli všichni a nedalo se bez toho žít, asi bych byl v průseru. :o) Jestli vám co chvíli shoří hardware, tak to máte blbý.

Nezapomněl, počítal jsem s tím, že z poslední věty bude jasné, že jsem si plně vědom toho, že to nemusí být požadavek všech lidí na této planetě :-) Mám podezření, že to bylo jasné i Vám a jenom se snažíte dělat čest své přezdívce ;-)

Už nechci mořit tohle vlákno off-topicem, takže přeju příjemný zbytek diskuze.

Existuji nastroje jako napr. SkyTool, ktery pouziva Skype pro sve reseni - veskera databaze uzivatelu Skypu jedou na PostgreSQL na 16 serverech. Jinak Core Team si je vedom nedostatku replikace primo v jadre a na PGConu bylo minuly tyden rozhodnuto, ze je to jedno z hlavnich priorit pro 8.4. Blize se podivejte na ruzne prednasky na www.pgcon.org.

Ano, toto je velmi potěšující správa.

A několik týdnů na naučení základní administrace :DD

Nejzákladnější rozdíly mezi FB a PostgreSQL, tedy jinak řečeno věci, které způsobují, že pro část aplikací je vhodný jen jeden ze dvou těchto serverů (pokud se nic z toho netýká aplikace, kterou chcete provozovat - což je případ mnoha aplikací - jsou výborné oba):

- PostgrSQL umí oproti Firebirdu navíc vlastní datové typy, vlastní typy indexů, několik server-side programovacích jazyků, fulltext search (kvalitu jsem ovšem nezkoušel), několik hotových indexů pro prostorová data (nad tím stojí PostGIS, který si lidé chválí).

- Firebird se oproti PostgreSQL mnohem jednodušeji spravuje, dá se i embeddnout do aplikace jako knihovna, na Windows není problém přibalit ho k aplikaci, aniž by si toho uživatel všiml. Taky je hodně silný co do národních kódování v řetězcových polích.

Náročnost nasazení PostgreSQL je celkem malá, nároky Firebirdu jsou ještě menší. Ale to se týká jen samotných serverů, co s nimi budete dělat, to už je na Vás a má to mnohem větší vliv. Těch padesát až sto uživatelů by Firebird zvládl v běžném OLTP provozu již před deseti lety na serveru s Pentiem. Firebird hlavně trošku omezuje poměrně malý počet nástrojů (v porovnání s PostgreSQL), ale především malá podpora v linuxových distribucích (je to trošku víc DIY). Ale má zase skvělou podporu v Delphi. ;-)

U Firebirdu se přenos holé databáze přinejmenším mezi platformami nedoporučuje, spíš přenos zálohy v "transportable backup" formátu. Nicméně ani tahle operace (dost rychlá, pokud vím, několikrát rychlejší než dump a restore u PostgreSQL) zřejmě není zapotřebí při prostém stěhování databáze mezi adresáři nebo i mezi stroji téže platformy.

Pokud se nechcete mořit s hákováním ILIKE do Firebirdu, můžete aspoń v některých případech použít CONTAINING. Případně existují nějaké ty UDF knihovny. Tady má PostgreSQL oproti Firebirdu výhodu prostě v tom, že je větší. :-) BTW, v OpenOffice.org jsem tak nějak neměl problémy, ani s JDBC, ani s ODBC driverem pro Firebird.

A takovou víceméně oficiální dokumentací Firebirdu je výborná knížka, asi o 1400 stránkách, pokud započítám "upgradovací" dodatek, co nedávno vyšel. To je asi tak jediná investice. PostgreSQL by toho teoreticky měl umět mnohem, mnohem víc, ale jeho nejnovější oficiální dokumentace má jen 1900 stránek, takže je možné, že poměr stránky/fíčury (a tedy vyčerpávajícnost, s tím, že nic důležitého nezůstalo přehlédnuto) je dost možná mnohem lepší u Firebirdu. Nicméně u PostgreSQL to zase asi kompenzuje komunita, abych mu nekřivdil. :-) (Nějak mi ale chybí dobré aktuální knihy o 8.x řadě.)

V cestine asi nic nebude, v anglictine to taky neni zadna slava - ta dokumentace, prestoze ma uz skoro 2000 stranek neni tak hrozna, a neni duvod pro psani redundantni literatury. Pomerne dost informaci je na planetpostgres, pripadne na http://www.pgsql.cz/index.php/Kategorie:%C4%8Cl%C3%A1nky

Plus ke stazeni jsou tutorialy pro 8.2: http://www.pgsql.cz/index.php/Jednodenn%C3%AD_%C5%A1kolen%C3%AD_PostgreSQL

Jů, díky za ty linky! :-) Potřebuju se PostgreSQL naučit, a tohle se určitě bude hodit.

Jů, díky za ty linky! :-) Potřebuju se PostgreSQL naučit, a tohle se určitě bude hodit.

U Firebirdu db soubor zkopírovat v zásadě lze, ale je nutné zajistit, abych se souborem pracoval opravdu jenom já a dát si pozor, jestli není různá verze Firebirdu (nejde ani tak o verzi Firebirdu, jako o verzi ODS - on disc structure). Proto se doporučuje backup a restore. Pro rychlý backup/restore, nebo pro přírůstkový backup, je od verze 2 nástroj nbackup pro bezpečné kopírování db souboru přímo.

Ten ILIKE tam opravdu není (alespoň o tom nevím), ale lze udělat třeba:
WHERE UPPER(NAME) LIKE UPPER('nOvÁk%')
plus si případně udělat index: CREATE INDEX .... COMPUTED BY (UPPER(NAME))
Jde to, ale je to trochu obcházení :-)

Pokud jde o to správné třídění v UTF-8 (bylo v předchozím příspěvku), to mi správně fungovalo ve FB 2.1 (je na spadnutí, zatím to byla RC verze), který má CREATE COLLATION .... Pak si mohu udělat collation třeba UNICODE_CZ, UNICODE_DE, ... a atribut JMENO si pak mohu správně třídit v u nás, Německu, atd. "Distribuční" collate UNICODE bere C, Č a CH stejně, takže se dočkáte setřídění Česnek - Charvát - Cuchal. Převod kódování mezi db a klientem fungoval v pohodě už v InterBase, v konzolovém isql je na to SET NAMES ..., v programu to říkám při připojování k db, v Pythonu třeba: db = kinterbasdb.connect(dsn='hostname:alias', user='USER', password='heslo', charset='WIN1250', dialect=3)

Já jsem to české UTF8 collate zkoušel také na FB2.1 RC2, ale bez úspěchu (embedded verze na Win). Vygooglil jsem v nějakých diskusích, že je možná potřeba plná verze ICU, ale ta jednak byla přeložena jinou verzí microsoftího kompilátoru, druhak embedded FB s plnou verzí ICU rozhodně nemá ty slibované cca 2 MB, ale několikrát tolik, takže by to mělo spíš smysl pro serverovou FB. Možná jsem to ale vzdal moc brzo :-). Nakonec mne docela uspokojily ty možnosti collate u win1250 - zvláště WIN_CZ_CI_AI - to mi docela dobře nahradilo ten ILIKE - alespoň u některých polí.

To souhlasí, mám stejnou zkušenost, bylo potřeba dát plnou verzi ICU. Ale šlo si s tím pohrát a dát tam jenom nějaké dll knihovny, nebylo třeba celé ICU. I tak se ale samozřejmě velikost z původních 2 MB zvětšila...

Co se tyce Firebirdu, tak jeho zakladnim nedostatkem je skalovatelnost. V classic verzi sice vytvori klienta pro kazde spojeni, ale jelikoz nesdili buffer cache, tak se musi slozite zamykat a synchronizovat, takze v podstate na vice procesorovych strojich mu dojde brzo dech. PostgreSQL oproti tomu skaluje velmi dobre do 8-12CPU.

To Vulcan taky. :-) Je pravda, že nad tisíc uživatelů nastávají se "starým" Firebirdem trošku trable. Nicméně myslím, že pokud tazatel doposud dělal svou databázi v Accessu, tak ho tohle tolik trápit nebude. :o)

Ak nechces nejak radikalne menit platformu a trapi ta otazka financii, stoji za zamyslenie MSSQL2005 express edition http://www.microsoft.com/sql/editions/express/default.mspx (neni som LO) - ma urcite obmedzenia, najma max. velkost jednej DB (4GB).

Moja osobna preferencia je pgsql aj pre velmi male projekty a to jednak z dovodu existencie PgAdmin, druhak moznost pisat procedury takpovediac "v jazyku akom len chces". V zaciatkoch mi pre pgsql hovorila aj dobra kompatibilita so standardom, takze uvaha "nechcem zistit, ze sa musim ucit veci, z ktorych aj tak 50% potom nevyuzijem" uplne odpada - je to skor tak, ako hovori MS marketing, ze mozes byt kludny, ak tvoje potreby casom rastu.

Dakujem za odpoved. Nad MSSQL2005 Express Edition som uvazoval, ale vadili mi obmedzenia. Ked som narazil na limit 2 GB, tak asi narazim casom aj na 4 GB ;-) (a pocet uzivatelov).

Povodne som sa mierne priklanal k FB, ale asi zacina viest PostgreSQL. :)

Predpokladam, ze ked idete nasadzovat "vykonnejsiu" databazu pre podnikovy informacny system, mate na to aj nejaky budget. Mate? Alebo chcete proste nasadit nieco, co bude zadarmo, kde si vygooglite nejaku odpoved v pripade problemu a o co sa nebudete musiet starat? V tom pripade je to viacmenej jedno. MySQL, PostgreSQL, Firebird pouziva kopec vlastnych ficurok, niekedy je pristup lepsi, niekedy horsi, no je dolezite vediet, co od toho ocakavate. Skuste si urobit zoznam poziadaviek a rozhodnite sa podla nich. Ak ste v pozicii vyvojara, ktory tvori nejaky informacny system a potrebuje sa rozhodnut pre konkretnu databazu, skuste sa rozhodnut podla vasich zakaznikov.
Z mojeho pohladu mam dobre skusenosti s Oracle, MSSql, Postgresql, Mysql. Firebird ma nepresvedcil nicim, co by stalo za zvazenie. No flame please.

Ehm... s budgetom bol problem - nebol. :-) Ani na hardware, ani na software. A teraz nie je ani na mna. ;-))

Ako vidim, podla poziadavok ktore som zadal sa rozhodnut neda.

Rejpal mi napisal:
Firebird se oproti PostgreSQL mnohem jednodušeji spravuje, dá se i embeddnout do aplikace jako knihovna, na Windows není problém přibalit ho k aplikaci, aniž by si toho uživatel všiml
Firebird hlavně trošku omezuje poměrně malý počet nástrojů (v porovnání s PostgreSQL)

Tak teraz neviem. :)
Asi bude najlepsie, ked sa pozriem podrobnejsie na oba, mozno aj vyskusat treba (co mi ale zaberie nejaky cas a ten ma momentalne tlaci) a potom sa rozhodnem.

Dakujem vsetkym za odpovede.

Přesně tak, zkuste obojí (Firebird a PostgreSQL) a uvidíte, oba jsou dobré a oba mají něco, co nemá ten druhý, Rejpal to celkem pěkně shrnul. U nás na Firebirdu děláme (prapůvodně od InterBase 4) a stěžovat si v žádném případě nemůžeme. Běží nám na tom, mimo jiné, třeba systém na výpočet a vyplácení důchodů a jiných sociálních dávek, jde o to měsíčně vyplatit cca 50000 lidí, novým podle zadaných dob vypočítat výši důchodu, pravidelné i nepravidelné (jak si vláda vzpomene ;-) valorizace plus archiv plateb za asi 10 let zpět a vše běží jak má. Ale na PostgreSQL by to jistě běželo stejně dobře :-).

Pro prográmky, které mají běžet jednouživatelsky na jedné stanici, je výborná embedded verze Firebirdu - jde vlastně o klientskou knihovnu s kompletním serverem a na stanici pak není třeba nic instalovat, omezení je, že k datům má přístup jen jeden proces. Přechod na síťový víceuživatelský provoz pak spočívá jen v nainstalování serveru a přenosu databáze na něj, v tu chvíli je z toho "dospělý" server.

Jinak k Firebirdu je pěkná kniha od Pavla Císaře (vydal CPress), pokud jde o další nástroje nebo kompletní dokumentaci (obojí se Firebirdu vytýká, že není), podívejte se na www.firebirdsql.org a www.ibphoenix.cz. Obojí existuje kvalitní, ale placené (např. IBAdmin nebo tištěná kniha s dokumentací), tak i free (třeba FlameRobin, dokumentace v různých pdf), ale ne tak učesané.

Firebird nepouzivam, takze tezko srovnam, ale co si na PostgreSQL chvalim je vertical partitioning coz se u rozsahlych tabulek hodi a zmena ve vykonu je znacna. A pak online backup. (Databazi mam cca 100GB, nejvetsi tabulka ma cca 55mld. radku).

No tak online backup je snad zamozřejmost :-), Firebird (nebo spíš jeho předchůdce Interbase) má online backup snad někdy od osmdesátých let. Pokud jde o ten vertical partitioning, dá se řešit pomocí pohledů. Ve Firebirdu jsou pohledy s joinem 1:1 tzv. "přirozeně aktualizovatelné", takže se s nimi dají provádět operace DELETE, INSERT a UPDATE a ono to tak nějak "funguje samo". Uznávám, že nativní řešení asi může být užitečnější ve více případech, protože výkon ve všech operacích ukousne méně a v těch náročných ho naopak více přidá. Zatím si ale, pokud vím, nikdo nestěžoval, ani ti, co mají databáze jdoucí do terabajtů. Kdyby ta potřeba vyvstala, jistě by tam něco takového už přednostně bylo. Nicméně tazatel se asi na takovéhle čachry (soudě z jeho dotazů) tak jako tak nechystá.

Mimochodem, 800 gigabitů a 55 miliard řádků znamená 15.61 bitu na řádek, něco pod dva bajty :-). Buď tam máte něco špatně, nebo je PostgreSQL skutečně extrémně dobrá databáze, protože tam by se podle teorie informace nevešel ani primární klíč, pokud by neměl alespoň nějaké rozdílové kódování. :-)

Moje zkušenost s PostgreSQL je vesměs pozitivní. Robustní, výkonný (dal se používat i na i486 s 48MB RAM), jednoduše nastavitelný. S Firebirdem nemám osobní zkušenost.