Open-source databáze jsou o 50 % levnější

$SUBJ su asi idealne miery pre opensource :)

fakt, rozhodnite sa ze kolko to teda je, ci 50 ci 60 :D

lol

"průměrné úspory 50%" x "až o 60%"

je doporučována? Postgres žere jeden proces na spojení a mysql má dost ořezanou SQL syntax. Je na tom firebird lépe?

Doporučil bych MySQL s InnoDB. Rozhodně nejlepší poměr rychlosti a schopností.

:-)
Doporučil bych PostgreSQL - má zcela jasnou licenci a budoucnost, umožňuje psát rychlejší aplikace a hlavně je velice spolehlivá.

Zcela se s Vami ztotoznuji. Clovek nesmi jen verit radoby specialistum, ktery nadavaji na rychlost oproti MySQL.

PostgreSQL? Potom poprosim priklad ako vypnut/zapnut autocommit (najlepsie v Jave), pretoze od verzie pg 7.4 nie je tato funkcia podporovana.

Firebird má tři verze - Classic, SuperServer a Embedded:

Classic je na každé spojení jeden nový proces. Výhodou je využití více procesorů a že při chybě a pádu serveru přijde o spojení jen jeden klient, ostatní si jedou vesele dál. Nevýhodou je o trochu větší režie (spíše na Win platformě, na UNIXech je to celkem fuk) a není sdílená cahe stránek.

SuperServer je jeden proces a každé spojení je nové vlákno. Výhodou je menší režie, rychlejší navázání spojení (výhoda u např. www aplikace) a sdílená cache stránek databáze. Nevýhodou je nemožnost využití více procesorů a při pádu serveru se přijde o všechna spojení.

Embedded je vlastně SuperServer zabalený do sdílené knihovny. Aplikace si pak při spuštění dynamicky přilinkuje klienskou knihovnu (ve které je ale i server) a jede se, samozřejmě k databázovému souboru pak v jednu chvíli může přistupovat jen jeden proces. Ideální například na jednouživatelské aplikace, které pak nevyžadují instalaci nebo na databázové aplikace spustitelné bez instalace z CD.

Aktuální verze je teď 2.0, verze 3 má být spojení FB 2, Vulcanu a Yaffilu a mimo dalších změn by mělo jít o spojení výhod SuperServer a Classic.

Jinak Postgres neznám, ale má být vnitřkem velice podobný Firebirdu, proti mySQL mi Firebird připadá poněkud dospělejší - prostě transakce, triggery a uložené procedury tam jsou běžná věc, nebylo to tam postupně dolepováno.

Firebird je velmi dobrá databáze, používali jsme ji v jednom produktu a byla lepší než Oracle nebo MSSQL. Bohužel zákazníci chtějí nejvíce tu nejhorší - MSSQL. Kdybych měl dělat nějakou spolehlivou aplikaci, tak vybírám Firebird.

Jo, to je klasika - musíme koupit MS SQL, protože je za tím velká firma a v sobotní IT příloze novin psali, že je nejlepší, kdežto nějaká opensource databáze, na to není záruka a navíc je to hračka několika magorů, co si myslí že změní svět... Přitom InterBase 5 byla poměrně drahá databáze stavěná na stejnou úroveň jako ostatní velké DB (Informix, Sybase, MS SQL, ...), než byla verze 6 uvolněná jako opensource a vznikla tak i větev Firebird.

Nám na Firebirdu (na verzi 1.5, 2.0 začínáme zkoušet) běží v práci databáze pro vývočet a výplatu důchodů. Teď je tam cca 40000 aktivních dávek, ty se vyplácí každý měsíc, s každou výplatou vznikají řádově staticíce záznamů (dávky mohou mít srážky a obstávky, musí se archivovat historie plateb, vytváří se převoďáky pro poštu a banky, které se archivují) a zatím si tedy chrochtáme blahem. Uptime serveru, což je současně doba kdy byl naposledy instalován, je asi 500 dní (bohužel to nedavno přeteklo) a za tu dobu žádný problém.

Tak já mám s Firebirdem zatím bohužel spíš negativní zkušenosti. Vyvinuli jsme v Delphi systém, kde několik desítek klientských aplikací přistupuje přes Internet k databázi - většina z nich nic nedělá, jenom čeká na event, aby provedla pár malých selectů a překreslila jeden grid. Firebird je Superserver, bohužel na Windows.

První problém nastal, když nám v náhodných intervalech, typicky několikrát za den celý proces fbserver zamrzl. Ukázalo se, že je to známá chyba, dokonce opravená v CVS 2.0 (blokující accept() na eventovém portu). Opravit to ve stabilní řadě 1.5 se ale nikdo nechystal (ani po dotazu ve vývojářském mail listu), a to v době, kdy 2.0 byla ve stavu tuším RC3. Pokoušeli jsme se zkompilovat si opravu sami, ale na Windows je to taková změť baťáků a externích utilit, že ani po celodenním úsilí to náš člověk nezvládl. Proto jsme si (za peníze) nechali zkompilovat vlastní build jedním z vývojářů FB.

Tím jsme se posunuli jen o kousek dál, k volání bind() s neinicializovanou proměnnou, navíc bez kontroly návratové hodnoty. Po této opravě už FB běží bez výpadků, ale s nevyhovující výkoností - 10x souběžně spuštěný stejný select běží 10x déle (plus režie daná přepínáním threadů). Databázím moc nerozumím, ale čekal bych, že po prvním dotazu už se výsledek načte z cache.

A to už vůbec nemluvím o replikaci db nebo dokonce clusterové řešení. To už se např. MS SQL nejeví jako špatná alternativa (a to říkám přes svůj značný odpor k microsoftí platformě).

> Tak já mám s Firebirdem zatím bohužel spíš negativní zkušenosti.

Nic není dokonalé ...

> Firebird je Superserver, bohužel na Windows.

Inu, když se pokoušíte desktopový operační systém nasadit na server, nedivte se, že máte problémy :) (ono i ten "Windows Server" je serverem pouze podle názvu - ve skutečnosti je to tentýž Windows, který běhá na desktopech, pouze poněkud jinak nakonfigurovaný. Binárky toho "Windows Server" jsou naprosto identické s některou z desktopových verzí, bohužel se nedá jednoduše zjistit, z kterou. Nebo se minimálne kompilují ze stejného zdrojového kódu).

> Databázím moc nerozumím, ale čekal bych, že po prvním dotazu už
> se výsledek načte z cache.

Výsledek dotazu do databáze se (na rozdíl od třeba výsledků přístupu k filesystému) obvykle necachuje, protože když v databázi dojde k změne, je velmi obtížné zjistit, jak tu cache s tou databází synchronizovat, protože ovlivnení výsledků dotazu změnou byť i jednoho záznamu nemusí být jenom triviální výměna starého obsahu záznamu v zacachovaném výsledku za nový (kupříkladu ten nový nemusí splňovat WHERE klauzuli (pak musí z výsledku príslušného dotazu zmizet) ale můžou nastat i velmi složité změny výsledku, když se tabulka, ve které se změna provedla, v tom dotazu používá jako spojovací tabulka). Proto většina systémů řízení bázy dát (tak se nadává tomu kusu softwaru, který vyřizuje dotazy a stará se o databázi) žádnou cache na dotazy nemá.

Nicméně ve vašem případe (pokud uprosřed tech deseti dotazů neprovádíte žádné změny, což asi ne), výkon by šlo zvýšit velice jednoduchou cache, která jednoduše svůj obsah zapomene při jakékoliv změne v databázi.

> A to už vůbec nemluvím o (...) clusterové řešení.

Dělat takové věci se systémy od Microsoftu by mohl jenom zoufalec nebo jejich zarytý skalní příznivec. Když pomineme fakt, že budete potřebovat licensi pro každý ze těch strojů v tom clusteru (a nejspíš ne ledajakou), každý ví, že na clusterové řešení je potřeba UNIX nebo něco podobnýho (čti Linux :) ), který byl pro takové nasazení vyvíjen už dlouho, ne desktopová slátanina se jménem MS Windows, pro kterou je něco takovýho jako cluster pořád ještě horkou novinkou.

> To už se např. MS SQL nejeví jako špatná alternativa (a to
> říkám přes svůj značný odpor k microsoftí platformě).

MS SQL si může (na rozdíl od Firebirdu) od systému made in MS vyhádat vyšší výkon některých, z hlediska výkonu klíčových, operací. Dělá to s použitím tajných systémových API, které jsou popsaná pouze v zapečetěných dokumentech s nálepkou TOP SECRET - EYES ONLY (přísně tajné - pouze k nahlédnutí). Taky je dosti možné, že tu velice jednoduchou výsledkovou keš, která svůj obsah zapomíná při změne obsahu databáze, taky obsahuje. Takže jo, na systémech od MS může být MS SQL opravdu dobrá alternativa. Jenomže pokud systém od MS na serveru používat nemůžete nebo nechcete (což je vzhledom k desktop-centrickosti celkem pochopitelné), pak je MS SQL tá nejhorší možná alternativa a to jednoduše proto, že na ne-MS systémech MS SQL jaksi neběhá :)

> FB běží bez výpadků, ale s nevyhovující výkoností

Ta může být způsobená taky velmi malou velikostí diskové cache, kterou Windows používá. Jejich cachovací algoritmus neví obsloužit více jako nejakých 37 MB cache (bez ohledu na to, kolik RAM je nacpáno do počítače), což je opravdu málo, když jsi vezmete, co všetko Windows ke svému běhu potřebuje. Pro porovnání, Linux umí pro cache využít veškerou volnou fyzickou RAM, což u mého stroje (768 MB RAM) dělá klidně i několik stovek MB.