Názory k článku
Firebird SQL 1.5 za dveřmi

AFAIK donedávna byl PostgreSQL považován za nejlepší free databázi, nicméně v poslední době se prý dost zlepšilo MySQL, ojevil se Firebird a ta věc od SAPu, takže se táži, je dnes nějaká z alternativ lepší volba než PostgreSQL? Je o tolik lepší, že by to ospravedlnilo migraci? Jde mi spíše o serverové nasazení, z toho důvody pro mě např MS Access není databáze.

Ja si nejsem moc jisty v cem se MySQL zlepsilo. Nedavno jsem si ji opet nainstalovat a velmi jsem zajasal kdyz jsem v manualu zahledl sluvka jako Stored Procedure a View. Opet jsem byl znechucen, jelikoz to pouze slibovali do dalsi verze. Myslim si, ze dokud MySQL nebude toto podporovat, tak se s tim moc poradnych projektu delat neda. Ted je to vicemene jednoucelova zalezitost, napr. cteni z katalogu (a i to musi byt mazec v tom vyvijet) ...

Jasne, ted se tady na me nahrnou priznivci MySQL a budou argumentovat tim, ze napr. Centrum to pouzivat atd. Jasne, souhlasim, ale pokud budu chtit cast logiky presunout na db server, tak se u MySQL asi moc nezadari.

Velmi se mi, ale zacina libit FireBird, jelikoz ma vse co potrebuji - SP, view, triggers ... Bohuzel jsem nemel jeste prilezitost ji poradne odskouset a zajimalo by me jak je na tom z hlediska vykonu. Nemate nekdo zkusenosti?

MySQL je podle me dobre tak akorat pro web. Rozumne se s tim pracovat neda - view, case, select from select ..... to jsou naproste zaklady, bez nichz se neda seriozne pracovat. Firebird je super, akorat mam vzdy problem s instalaci pod windows.... pokud je tam instalator je to v pohode, ale upgrade ze zip balicku se mi nikdy nepovedlo :-)

Přesně!

Jak ukázaly naše firemní testy, ve vybírání dat nemá MySQL konkurenci (možná dobře nastavený Oracle). Umožňuje si předem setřídit data, aby se pak nemusely pokaždé třídit. Zkrátka a dobře - na webové informační systémy či vyhledávače to je volba no. 1.

Jakmile ale začnete data měnit, z MySQL se stává věc, která spolehlivě chodí na malých aplikacích pro malé pracovní skupiny. Já sám jsem nad MySQL postavil firemní informační systém, který provozují zatím dva uživatelé. Víc od ní nemůžete čekat.

Je to ale skvělé, že tu MySQL je. Perfektně doplňuje nabídku. Toť můj názor.

S tím se dá jen souhlasit. Nejen vybírání, ale i nahrnutí dat co do rychlosti v MySQL nemá konkurenci. (Jen bych doplnil, ža ani když přijely odborníci od O?????, I?? i M? {nesmíme jmenovat} a ladili to přímo u nás, tak nedokázali na stejném HW tento inteligentní fs překonat.) Je to holt tak, když chcete data rychle nalít, rychle je indexovat a pak je rychle číst a tyto operace si sami ošéfujete, tak jsme nic lepšího než MySQL nenašli nejen mezi open, ale ani close. Pokud od toho nečekáte zajištění datové integrity, SP, Triggery a pod. je MySQL dobrá volba. Bavíme se řádově 100GB, miliónech záznamů a desítky klíčů na agregaci 1:10 - 1:10000 cca. Ale "účetnictví bych na tom nepostavil". To je o něčem jiném. Volba mezi Postgres a Firebird je těžká a každé má něco do sebe.

Dovolil bych si doporucit DB systemy na bazi MUMPS.
Treba 'Cache'. Ty jsou BEZKONKURENCNE nejrychlejsi.

Ciste teoreticky:
1/ Vezmu system, ktery neobsahuje nejake feature a je vyladeny na max vykon delat to co chci (nepotrebuji ony feature!).
2/ Ted si vezmu nejaky jiny system, ktery tyto feature obsahuje a je vyladen jakkoli. Musi tedy obsahovat napr datove struktury, ktere ja nepotrebuji. Tyto datove struktury s vysokou pravdepodobnosti ukladaji na disk a pri jejich cteni to musi projit pres diskovou cache, pres datovy kanal, nacpat do pameti (tam na to hodim bobka). Code obsahuje nejaky kusy kodu, ktery se neprovadi, ale zavazy v pameti. Nejakej kod co musi poznat, ze tenhle zbytecnej kod se nemusi provadet a tem mi tam zase zavazi a navic se provadi. Atd, atd, atd ...

A ted mi ciste teoreticky reknete, jestli je sance ze system 2/ bude "BEZKONKURENCNE (nej)rychlejsi" nez system 1/ pri provadeni ukolu na ktery !nepotrebuji! feature, ktere ma system 2/. Myslim, ze to je ciste teoreticky nemozne. Az mi to predvedete v praxi, tak se vam pokusim uverit, ale potom nejspis skoncim v blazinci, protoze to mi mozek nebere a nabouralo by mi to zakladni paradigmata.

P.S.: Vsimete si prosim, ze ja opravdu netvrdim, ze MySQL je nejrychlejsi, nejlepsi, nebo jina databaze. Ja jen tvrdim, ze na urcitou mnozinu uloh je BEZKONKURENCNE (nej)rychlejsi (a to radove :) nez databaze, ktere toho umi vic (o CACHÉ jsem dost slysel a mozne je vsechno) a IMHO je to zpusobeno mimo jine tim, ze proste ty vlastnosti nema, neuklada zbytecna data, neprovadi zbytecny kod atd, atd, atd ...

MySQL je databaze, ktera vznikla jako ocesana prave od tech vlastnosti, ktere zdrzuji nejvice. MySQL ma sve urceni a misto, a zvlada velke zateze, pokud ji pouzijete na to, na co je stavena.

Ja si proste myslim, ze to vubec nebyl spatny napad takovou databazi postavit. Myslim si, ze nejvetsi problemy u MySQL jsou tyto:

1) Její licence.

2) Lidé, kteří se jí snaží porovnávat s jinými databázemi.

Technicka. Napr MS SQL umi setridit data v tabulkach fyzicky na disku. Oracle IMHO taky.

Já si nejsem u FireBirdu příliš jistý, jak moc dobře pracuje při větším množství současně pracujících klientů. Určité provedené soukromé testy o tom nehovoří moc lichotivě.

Navíc znám jednu firmu, která zkoušela na Interbase aplikaci s 50 klienty s poměrně malou zátěží od každého klienta, a Interbase prý už docela selhávala. Nakonec se vydal po zkušenostech vnitřní zákaz používání Interbase databáze.

Otázkou také je, jak moc dobře zvládá klient u Intebase/Firebird multithreading...

Osobně mám s tím zkušenosti docela dobré. Musíte si pouze dobře rozmyslet, jak zvolit u jednotlivých klientů isolation level (v závislosti na způsobu využití). Pokud například necháte defaultní nastavení z Delphi/C++ Builderu, je to taková "sázka na jistotu", ale z hlediska efektivity při větší konkurenci nic moc. Také pomáhá používat pro ty akce, které nic nezapisují, read only transakce.

O těch izolačních úrovních vím, a tak se také nastavovaly na nižší hodnoty. Ale na druhé straně má Interbase/Firebird multigenerační architekturu a tak by se měl s tímto problémem poprat podstatně lépe, než klasické transakční databáze.

Určité problémy s velkým počtem klientů mohou být u varianty SuperServer (více vláken, jeden proces), ale rozhodně nevznikají u varianty Classic Server (více procesů, jako u PostgreSQL). Classic ovšem není k dispozici na Windows, ale pouze na Unixech. Borland bohužel (nebo naštěstí?) ukončil vývoj verze Classic, a nadále se věnuje jen Super Serveru. To přivedlo řadu velkých zákazníků Borlandu k Firebirdu, který od verze 1.5 nabízí Classic rovněž pod Win32.

Mimochodem, na Unixech je Classic server v lokálním připojení vlastně embedded server (server ve sdílené knihovně, přimo připojovaný k aplikaci). Síťově to jede přes inetd/xinetd. Classic na Win32 je jen síťový, pro lokální použití je nový Embedded server. ten ovšem vychází z architektury Super Server :-)

Díky za skvělou odpověď.

No ja jsem pouzival Interbase nevim jake verze na novellu s klienty psanymi v delphi 1.0 a chodilo to naprosto bozsky. Meli jsme 50 licenci, tenkrat byly asi po 3000 Kc. Tusim to nikdy nebezelo na plny pocet licenci (ony se stejne nepocitaly) ale tech 40 klientu tam bylo a nemel jsem pocit, ze bych se blizil limitu. Navic to meli s novellem skvele provazane, takze se pouzivaly interni transakce filesystemu. Nezapisovalo se do toho hlavniho souboru, ale do WAL logu a ty se pak prenasely na hlavni databazi.

Mozna mel nekdo problemy s win verzi, ale to mohlo byt klidne systemem a ne Interbaskou. Jedine co me privadelo k silenstvi bylo, ze jejich isql neni linkovane s libreadline. Jenze to neni ani oracle a co hur, isql to neumelo v roce 93, oracle to neumi dneska.

Klient isql z Firebird 1.5 (zkoušel jsem RC4) umí historii a editaci příkazové řádky, narazil jsem jen na dva problémy (možná za ně nemůže isql ale já). První je zobrazení znaků s diakritikou (fungují, ale zobrazuje se jako 'M-a' apod.), možná mu lze nějak říct, jaká je znaková sada, jen jsem to zatím nenašel (resp. nehledal). Pak jsem měl také problémy s editací, pokud je řádek delší než řádek terminálu (editace funguje, ale zobrazení je opět poněkud podivné).

Člověk vnímá databázi celkem jako celek se systémem. Když hodnotím FB/IB spolu s Windows, tak jí tak hodnotím.

Novell je pro mě mrtvola. Měl jsem tu čest sem tam něco naprogramovat jako modul pro Novell. To, člověk pak velmi rychle pochopí, proč Novell slouží hlavně jako fileserver, a skutečných aplikací je pro Novell pomálu. Ne, velmi si přeji už nic s Novellem nemít společného, jako fileserver a printserver možná, ale nic víc.

Prostě pokud databáze nepracuje dobře na systému, o který se jedná, není to pro mě a pro můj účel vhodná databáze.

MySQL bude perfektni - ve verzi 5. Hral jsem si s ni a vypadala vazne skvele. Ale zatim ji chybi tak cca 2 roky. Firebird je malej, hezkej a pro Borlandisty jako delanej. PostgreSQL stale chybi nativni verze pro win, dvoufazovy commit, zachytavani vyjimek v plpgsql, replikace. Ale vsechno ostatni ma dotazenejsi nez konkurence, tj. mysql a firebird. Ve 7.4 i znatelne zrychlila. Takze asi tak :->. Dokonce i MySQL ma lepsi dokumentaci nez Firebird, a to je co rict. Kdyz mne tak napada, tak asi dokumentace je nejvetsi minus Fb. Rychlostne je PostgreSQL a Firebird zhruba na tom stejne, pouzivaji stejnou architekturu.

Pro replikaci PostgreSQL nedavno neco vyslo, viz. http://www.postgresql.org/news/147.html , multithreadovou verzi pro win taky nekdo dela, ale uz to neni free, verze pod Cygwinem mi finguje v pohode, na zatez sem to netestoval, jinak PostgreSQL neni myslena jako osobni databaze, takze nedostupnost win verze neni az tak kriticka, Jnak ten Firebird zachytavani vyjimek v PLSQL a dvoufazovy commit ma?

jestli dvoufazovy commit, to nevim. Ale zachyceni chyb ma urcite. PostgreSQL bohuzel v ToDo :->

Firebird má dvoufázový commit.

Nevim jak je na tom aktualni RC, ale zhruba pred mesicem prelozit Firebird dalo celkem zahul :->. Jednak se defaultne predpokladalo, ze uz mate nejaky Firebird nainstalovany, sem tam tam uklouzlo jeste i misto f na zacatku aplikaci, testy, ktere byli z nejakeho duvodu uprostred instalace padali, a bylo je treba odstranit.

Navic pro spusteni musite mit v etc soubor /host/equiv obsahujici localhost.localdomain

isql je oproti psql primitivni, ale asi se to ani nepredpoklada, ze by se pouzivala (nedokazal jsem v ni ani psat cesky).

Jinak jeho jazyk ulozenych procedur a triggeru, jak se jmenuje :-> celkem ujde (chvilku mi trvalo nez jsem pochopil jeho zapis na konzoli) - pekna vychytavka je deklarace vraceneho recordu (to mi v PostgreSQL chybi), binarky jsou skutecne mensi nez u PS, a navic mate moznost puzivat Fb na RO mediich - dokumentace je ale hrozna :->, vuci PostgreSQL (a i ta od Borlandu a jina neexistuje).

TestY bylY, instalace padalY, ... Ach ta čeština.

Kdybys radsi sam neco napsal a nemel u vseho jen debilni prominky. Svet by fakt byl lepsi.

Ale ma pravdu, tvarime se jako vzdelani lide s urcitou odbornosti, takze to pusobi dost divne.

pre vyvoj webu stacia mysql a postgresql. mysql sa hodne zlepsili a postgresql je proste zabehnuta istota. borlandovsky vytvor sa ma este vela co ucit hlavne co sa tyka podpory a zazemia. ja osobne tento DB nebudem ani skusat. radsej si prehlbim znalosti z mysql a postgresql. tolko moj skromny nazor.

Je to sice trošku pozdě, ale přesto si dovolím zareagovat.

Jaký Borlandovský výtvor? To není výtvor Borlandu. Jak, má se co učit? Zázemí asi nevidíte, protože je pořídně velké, podpora také. Nebo to bude tím, že jste se o IB/FB více nezajímal?

Je vidiet,ze o Interbase absolutne nic neviete!!! Interbase sa zacal vyvyjat v case ked vacsina z tychto ostatnych DB systemov ani neexistovala.Jeho povodnym autorom je Jim Starkey ktory pracoval vo firme DEC.Navrhol a vymyslel DB system JRD predchodcu Interbase vyuzivajuci multigeneracnu architekturu,ktoru neskor prebrali aj PostgreSQL a Oracle.V roku 1984 zalozil firmu Groton Database Sytem ktora sa premenovala na Interbase. z z databaze Jrd sa stala sucasna Interbase.Az vdaka roznym finacnym problemom dopadla situacia tak ze v 1989 firma Borlan odkupila Interbase.Borland vsak znacne zavahal a vcase ked zacal Interbase znova ozivovat a propagovat(1994) stratili uz mnoho zazkaznikov.Chybu v podstate urobila firma Borland ktora ju nepresadzovala a nevyvyjala zo zaciatku tak ako bolo treba.Nabuduce si aspon prestudujte fakty nez tresnete nejaku hlupost!

Technický dotaz: jak je to u nového FB s podporou ukládání v unicode? A je nějaká možnost fulltextového hledání v databázích?

Data lze v IB/FB ukládat v různém kódování (rozlišováno až na úroveň položky) a využít různého třídění pro dané kódování. mezi podporované znakové sady patří i UNICODE_FSS. Nicméně tyto znakové sady lze použít jen v datech, nikoliv v názvech databázových objektů.

Fulltext hledání není standardní výbavou IB/FB, ale existují rozšíření od jiných dodavatelů (např. Rubikon).

Používat národní znaky na názvy položek apod. považuju za prasárnu, takže to mě nepálí. Spíš ten fulltext. Chci to použít pro web, který mi nevydělá ani korunu, takže do něj hodlám investovat čas, ale peníze už ne. Není nějaké to rozšíření ve free verzi? Nějak se mi nepodařilo nic vygooglovat.
Zatím to vypadá spíš na poslední betu MySQL (ostatně než se dohrabu k dokončení, třeba už bude ostrá ;-), ale přece jen - jsem zvyklý na transakce, sice nejsou nutností, ale pokud by to šlo s nimi, byl bych radši...;-)

pgsql fulltext:
SRC_DIR/contrib/tsearch
v 7.4 aj
SRC_DIR/contrib/tsearch2

No, pokud tomuhle někdo říká fulltext...
Tedy, hrál jsem si s tím někdy v zimě, možná že to předělali, ale pochybuju.

Ten "fulltext" co mate na mysli je nepouzitelny... Je proste na nic a pomaly. Cokoliv jinyho je lepsi...

MySQL transakce umí. Na druhé straně fulltextový index lze aplikovat pouze na tabulky MyISAM, které fulltext nezvládají...

No, vždyť jo. Já tam potřebuju oboje...:-(
Ještě je varianta cpát to paralelně do dvou databází, jednu s podporou transakcí, nad kterou by se normálně pracovalo, a druhou MyISAM, kam by se jednou za čas vysypaly data pro fulltextové hledání. Ale to už je docela šílenost, to se radši bez transakcí obejdu.

Dá se použít interní charset UNICODE_FSS, pokud ho použijete jako znakovou sadu při připojení klienta, budete dostávat data v utf-8. Hlouběji jsem to ale zatím nezkoušel, myslím, že je tam problém s tím, že nejsou definovány potřebné hodnoty pro collate.

Když už se autor zmínil o dokumentaci, mohl by alespoň upozornit na výbornou knihu "InterBase a Firebird" od Pavla Císaře, kterou nedávno vydalo nakladatelství Computer Presss. Nevím sice, nakolik může suplovat originální dokumentaci, ale je fundovaná, přehledná a jasná a zájemce o Firebird by ji rozhodně neměl ignorovat. Navíc je psána skutečným znalcem.

Knížku mám, zrovna ji čtu. Je výborná, recenze bude následovat.

Nesouhlasím. Neurážel bych tu knihu slovem "výborná", je ještě lepší, přinejmenším excelentně brilantní :) Tohle mi dlouho chybělo. Nemohu se odtrhnout od stránek...tentokrát ovšem papírových...

Knihu mam, mohu potvrdit, kniha je vyborne napsana,
doporucuji vsem, kteri se chteji IB/FB vazne zabyvat.

Docela bych uvital nastroj podobny phpmyadmin (resp. phppgadmin), v zakladnim baliku s firebirdem jsem nic nenasel. Slysel jsem, ze jich je vic, doporucite nejaky?

Obdobou phpmyadminu je IBWebAdmin na SourceForge, http://sourceforge.net/projects/ibwebadmin/
Velmi zevrubný katalog všemožných nástrojů pro IB/FB je k nalezení na
http://www.ibphoenix.com/main.nfs?a=ibphoenix&&page=ibp_contrib_download
Velmi oblíbený je např. IBExpert Personal (je zdarma), ke stažení na http://www.ibexpert.com/

Lepsi nastroj na administraci pres web(vyzaduje take PHP) je IBaseAdmin. Najdete ho na http://pkedu.fbt.eitn.wau.nl/ibaseadmin/ .
Problem techto admin. programu je zavislost databaze, aby bezela na lokalnim pocitaci. Hodne vyuzivaji spustitelne programy z Firebirdu misto, aby to resili interne sami. Pro praci se vzdalenou databazi je tyto programy potreba hodne upravit.

Před rokem a půl jsem pracoval ve firmě, kde se vyvíjelo nad Firebird 1.0. Pro správu jsme používali wokenní IBExpert a fungovalo to bezvadně. Zejména psaní uložených procedur a předávání result setů z nich bylo velmi kvalitně vyřešeno, ale i ty zmiňované views, vlastní dat. typy (domains), triggery atd.

Z trojice PostgreSQL, MySQL a Firebird bych asi Firebird preferoval, zejména pokud by se našel nějaký free grafický program pro administraci pod Unixem/Linuxem (možná už existuje, delší dobu to nesleduji).

Docela dobry program na administraci je IBAccces (http://www.ibaccess.org/). Jedine co mne na nem vadi je psani/uprava SP a triggeru (ty radsi piseme ve scriptech).
Zdrojovy kod je take dostupny (napsano v Delphi/Kylix).

Linuxoví puristé prominou, zmíním se o dvou vlastnostech Win32 verze FireBird, která je jinak také moc povedená.
Určitě stojí za zmínku i existence Embedded verze. Pomineme-li poněkud podivný způsob pojmenování binárek, který může působit problémy, je to moc pěkný databázový stroj.
Co mi naopak vadí, je klient pro Win32, který evidentně naprosto nezvládá podporu více vláken (multithreading). Nějaká agregace dotazů do aplikačního serveru potom buď naprosto degraduje výkonnost nebo vynucuje architekturu s více procesy.

Co vsechno umi ta Embedded verze? Jako ze aplikace pristupuje na data bez serveru?

Ten multithreading to je znama vec, ovsem, netestoval nekdo ty nove JDBC ovladace typu 4? Jak to chodi?

Embedded server je v podstatě klient a server v jedné knihovně. Umí to víceméně všechno, co normální Firebird, pouze funguje jen lokálně a neřeší autentizaci (autorizaci ano). Používá se pro aplikace, které běží jen na jednom počítači - výhoda je, že nemusíte instalovat a spouštět Firebird server.

Jak probiha autorizace bez autentizace, jsem-li tak smely?

Jednoduse, protoze jsou to dve ruzne veci.

Autorizace znamena, ze vas system pozna (treba ja jsem lzap) a umozni ruzny veci (treba muzu zapisovat do tabulky).

Autentizace je proces, kterym se overuje, ze ses to skutecne ty. Typickym prikladem pro databazovy server je jmeno/heslo/ip adresa, ale dnes se pouzivaji otisky prstu (malem jsem napsal PRSU ;-))) ci sitnice...

Zkratka a dobre nepises tam heslo, ale hlasit se muzes jako nekdo jiny, menit ROLES atd atp.

ps - embedded umi i MySQL, je to sikovna vecicka... hodne by se mi libil JDBC embedded ovladac, nevite, jestli to existuje? ;-)

V praci pouzivam Oracle, doma Interbase a nyni Firebird (+ vyvoj aplikaci v Delphi). Doma jsem kdysi z demo CDcek nainstaloval Oracle. Byl to neskutecny moloch a pochybuji, ze by ho nekdo pouzil doma. Pro domaci pouziti je Firebird naprosto idealni, rychly a nejsou s nim zadne problemy (a to mam jeste porad Celeron 366 MHz). Ke sprave pouzivam IB Expert Personal a dela se s nim skutecne dobre.

Zkuste se mrknout na http://www.sqlite.org/ je tam moc hezka mini databaze ktera umi skoro vse z sql92, hodi se pro studium zdrojovych kodu a je o neco rychlejsi nez mysql.

Firebird bych se bal nasadit na ostry server, preci jen se tam moc prepisovalo a menilo, ale pro embed reseni je idealni, protoze server zabira jen 800 kb.

Jinak postreSQL jiz davno neni nejlepsi databazi, zkuste si srovnat co umi s www.sapdb.com

snad http://www.sapdb.org, ne?

>Firebird bych se bal nasadit na ostry server, preci
>jen se tam moc prepisovalo a menilo, ale pro embed
>reseni je idealni, protoze server zabira jen 800 kb.

??? Dokázal bych ještě pochopit jistou zdrženlivost vůči verzi 1.5, ale verze 1.0.x je stejně spolehlivá jako kterákoliv InterBase 5.x/6.x. IB/FB má velmi dobré reference (banky, armáda, velké firmy, školství). Nicméně i verze 1.5 je již nasazována v ostrém provozu (např. Deutsche Presse Agentur, viz http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_deutchepresse).

Jinak pokud někoho zajímá srovnání MySQL a Firebirdu ía částečně i PostgreSQL), pak doporučuji diskuzi na http://forums.devshed.com/t62269/s.html

K te SAP DB:

Ma to hacek, zase to nebude free database, protoze SAP a MySQL AB uzavreli smlouvu a od verze 7.5 se SAP DB prejmenuje na MaxDB a bude ji prodavat MySQL AB. Samozrejme i se svoji licencni politikou, tzn. pokud produkt postaveny na MaxDB je komercni, musis zaplatit. Naopak, opkud muzes zverejnit zdrojak pod GPL, platit nemusis.

Viz. http://www.sapdb.org/7.4/sapdb_mysql.htm

Podle me to neni dobry tah ze strany SAPu. Jaky mate na tohleto nazor? Osobne se mi licencni politika MySQL AB vubec nelibi. SABDB byla distribuovana vyborne, server pod GPL a klienti a knihovny pod LGPL. Ted to chteji zmenit!

[...] . Jaky mate na tohleto nazor? [...]

Nu, ja ocekavam, ze podle teorie OpenSource (viz Katedrala+Bazar=ESR), se do nekolika mesicu objevi skupina vousatych zaopatrenych programatoru, kteri se chopi verze SAPDB 7.4 a "forknou" ji na vlastni verzi, ktera bude komunitou zavratnym tempem dale vyvijena (podle ESR objektivni nutnost). To povede k tomu, ze os-vyvojari mysql a jinych databazi budou sve produkty vylepsovat, jsa pod pozitivnim tlakem kvality new-sapdb. Vzajemne se touto open-source-konkurenci nastavi takova uroven vsech open source databazi, ze Oracle nahlasi bankrot. Asi takhle nejak si to predstavuji.

Je mi jasné, že svůj příspěvek myslíte ironicky, ale přesto na něj zkusím reagovat vážně. Spíš bych řekl, že jedním z hlavních faktorů, které mají vliv na vývoj Firebirdu, je právě tlak přímých (komerčních) konkurentů (Interbase a Yaffil). Vzhledem ke stále ještě relativně snadné migraci je tu vyšší tlak na udržení zákazníků. A samozřejmě to platí i obráceně: pokud Interbase (Yaffil) nebude schopna nabídnout oproti Firebirdu něco navíc, nebude u ní zákazníky nic držet.

Myslím si, že Borland je dostatečně poučen a mlátí se do hlavy. Manažera, který dostal nápad zveřejnit Interbase jako open source asi pro výstrahu potrestali. A Borland už nikdy nejspíš nic open source nevydá...

A proc tak soudite? Myslim, ze to byl dobry tah, ktery zakazniky jenom pritahne.

Že se Borland mlátí do hlavy je pravda, nicméně v dané situaci (kompletní rozpad divize IB jako reakce na neakceptovatelný "business plan" nového vedení) to byl docela dobrý nápad. že se později situace změnila a Dale Fuller (CEO Borlandu) změnil názor je věc jiná. InterBase Borlandu stále vydělává. Není to sice nic moc, ale na náklady na vývoj to stačí (a ještě zbude).

Můj osobní názor je, že Borland v současnosti vyvíjí InterBase natruc ostatním. Rozhodně ho nějaká IB neživí.

Jak na truc? To nechapu...

Někteří lidé od Borlandu reagují na odchod svých kolegů a vznik Firebirdu způsobem, který bych nazval uraženou ješitností. Aspoň to je můj dojem z některých jejich vystoupení. Takže Borland pokračuje ve vývoji Interbase, přestože to žádný velký ekonomický přínos nemá, už je proto, aby lidem z IBPhoenix ukázal, že udělali chybu a že se bez nich obejde. To je můj soukromý pocit.

Smlouvu mezi SAP DB a MySQL AB považuji naopak za skvělý tah. MaxSAP je určen pro střední a velké podniky (dle našich měřítek pro veliké a obrovité) a nevidím důvod, proč by měl být zdarma. Spolupráce je ovšem oboustranná (včetně výměny patentů), takže jistě ovlivní i MySQL . Ta se tak brzo může stát plnokrevnou databází. Rozhodně bych se tomu nebránil. Navíc MySAP zdarma zůstává.

S tim se da z jedne strany souhlasit. Pokud udelam informacni system postaveny na MaxDB (mala ceska firma o nekolika programatorech) a licence by byla unosna, tak proc ne. Na druhou stranu ale muzeme pocitat s tim, ze to budou pekne palky, licence za klienty a podobne.

Takze az tak dobry tah to zas nebyl. Pri vyberu databazove platformy nekdy hraje roli dostupnost a licence (cena). Firmy vyhledavaji LGPL, APL a Bsd-like licence.

Doufam, ze se SAPDB komunita rychle ujme a bude tu novy "Firebird". Bude to ale tezke, je to nesrovnatelne vetsi moloch nez byl Interbase....

> server Interbase byl stavěn spíše pro systémy
> Windows

Toto není pravda, neb hlavní platformou pro vývoj interbase byl unix a teprve verze 4.0 byla na Win platformě a teprve verze 6.0 byla relativně na Woknech spolehlivá.

> zachována 100% kompatibilita
ne tak docela díky opravě chyb a zpřísnění SQL standardu ne vše chodí a musí se lecos lehce upravit.

> nastavit velikost (počet stránek), kterou má
> server alokovat.

tady spíš se jedná o nastavení velikosti jedné stránky, pak je možné ještě stanovit serverovou cache pro danou databázi.

> definované funkce (UDF), ....
> nedovedu si představit, v jakých situacích ...

UDF je mocný nástroj, protože si lze do serveru doplnit teoreticky jakoukoliv funkčnost. Dají se s tím skvěle dělat exporty dat, případně je možné jednoduchou fintou pomocí UDF v aplikaci zobrazit šoupák o průběhu transakce a podobně...

Diky za upresneni, ve snu by me nenapadlo, ze mel Borland nekdy co do cineni s Unixy.

Nic neni na 100%, v tomto pripade je nutno to brat s nadsazkou.

Ona historie interbase je poněkud divočejší. Borland byla třetí nebo čtvrtá firma, která interbase vlastnila. Viz:
http://bdn.borland.com/article/0,1410,25302,00.html
nebo
http://www.cvalde.com/IbRoadmap.htm
(ale tato stránka je asi již mimo provoz, nicméně google jí má v keši :-)

Borland InterBase nevyrobil. Ta vznikla v roce 1984 (vlastne jiz drive u DELu, ale jako samostatna firma vznikla v 84). V roce 1989 ji koupila firma Ashton-Tate (vyrobce dBase), kterou nasledne koupil Borland v roce 1991. V te dobe byla IB již ve verzi 3.

Aha, ja jsem tu kompatibilitu pochopil spise z hlediska komunikace s db :).

udf se daj taky pouzit treba na full text indexy apod. (na to i knihovny existuji)

Kdo z vas objektivne meril rychlost DB? Mam pocit ze rychlost u MySQL je tak trosku zavadejici. Protoze v realu musi pak aplikace suplovat funkci DB a nemyslim, ze rychlost se zvysi, kdyz operace, ktere muze delat procedura nebo trigger, resi pro DB a tedy i data "externi" aplikace.

Navic od DB ocekavam trochu vice nez jen proste ukladani dat a jejich vybery.

Vim ze MySQL vyplnuje na trhu urcitou mezeru "skorodatabaze" :), ale ta uvadena rychlost je zavadejici. Mela by se k ni pripocitat i doba potrebna aplikaci pro dodatecnou kontrolu dat

Nicmene na ulozeni informaci o mych domacich mazliccich je plne vyhovujici:)))))))

A vase zkusenost drazi?

Ty testy odpovídají praktickému nasazení, pro které se MySQL hodí. Takže se testují prakticky jen selecty (hodně selectů) a s daty se prakticky nehýbe. Pokud potřebujete větší konkurenci klientů, kteří s daty manipulují, nebo přenést část logiky do vrstvy databáze (hlídání konzistence dat, automatické akce apod.), není MySQL vhodná volba. Proto se také u tohoto typu aplikací rychlost MySQL netestuje.

U každého databázového engine, ať už je to Firebird, MySQL nebo třeba Oracle, je potřeba mít na paměti, pro jakou oblast aplikací je konstruován a pro jakou oblast aplikací je vhodný. Extrémní názory typu "XYZ je ideální ve všech případech." nebo "XYZ se nehodí k ničemu." nemají smysl.

[...]Navic od DB ocekavam trochu vice nez jen proste ukladani dat a jejich vybery. [...]

A ja zase ocekavam nanejvys tohle. Aby byla moje aplikace prenositelna.

To je taky extremni nazor. Dovolim si dalsi extrem, psat tak, abych mel prenositelnost z Oraclu nebo MSSQL na MySQL je nicemnost a zvrhlost, a skoda prace a penez. Prenositelnost je hezka vec, ale nesmi to byt zaklinadlo. Sikovnym navrhem aplikace se necha z kazde databaze vyzdimat co se da!

Budto pisu maly veci a pouziju MySQL, nebo potrebuju dabelskou rychlost a pouziju taky MySQL, nebo umim jen MySQL a pouziji zas jen MySQL. Nebo se snazim aplikaci rozvrstvit, resim pristupy do db, zalohovani, pri hodinovym vypadku databaze naklady lezou do sta tisicu, pak pouziju MSSQL nebo Oracle (podle lidi, zeleza, systemu), nebo zas o tolik nejde, tak muzu pouzit Firebird nebo PostgreSQL nebo neco levneho co clovek zna. Dle Vericha, kumst je se spravne rozhodnout.

S většinou souhlasím. Jenom bych upřesil, že termín "malý věci" na začátku druhého odstavce se vztahuje spíše k velikosti metadat než dat. MySQL zvládá dobře i velké databáze (co do objemu dat), do úzkých se dostává (autor systému) v okamžiku, kdy je složitá jejich struktura.

Jinak jako možného konkurenta Oracle u "velkých" systémů bych viděl spíš DB/2. MS SQL je až "druhá liga", společně třeba se Sybase.

P.S. Verich???

sorry, ostuda Werich

"Druha liga"... tak presne o tom Pavel mluvil. Neni to zadna druha liga, s MSSQL a Sybase se musi pocitat a je chyba, kdyz to pri rozhodovani, kterou platformu pouzit, neuzavujes. V nekterych situacich je MSSQL nejlepsi, o tom neni sporu. Napr. kdyz klient ma MS Windows server, chce indexovat Word dokumenty a podobne... O zadne druhe lize nemuze byt ani rec!

Psat prenositelne informacni systemy je podle me blbost. Kdyz uz se pro neco rozhodnu, najmu programatory, mam delat support, tak se to musi dotahnout do konce. Vseho s mirou. A to ze nejaky webovy pocitadlo bezi na vice SQL serverech to je jasny. Vzdyt tam zadna logika neni...

JE TO DRUHÁ LIGA, no spíš třetí.

Dělám pro MSSQL už čtvrtý rok, předtím Oracle a je to NEUVĚŘITELNÉ utrpení.

Skoro nic to neumí a nepodporuje, neustále vnitřní chyby (třídění, integrita dat, stárnutí a "hnití" velkých uložených procedur), na nic se nedá spolehnout (náhodné chyby=neopakovatelné).

Prostě děs a hrůza. Kdybych měl možnost, tak od toho jdu okamžitě pryč!!

Pred par lety jsem chtel u zakaznika nasadit aplikaci s InterBase verze 4. Kdyz jsme to meli naplanovane, tak se bohuzel objevila Sybase (rodna sestra MSSQL) pro Linux. A protoze zakaznik je Sybaseidni, tak to chtel pod Sybase. A my, abychom se vyrovnali s vecmi, ktere Sybase neumi, napr. insert trigger pred operaci a i jine "drobnosti", jsme to cele museli nadesignovat uplne znovu. A tim myslim nejen databazi, ale uplne cely system i s datovymi toky. Musim konstatovat, ze Sybase byla a stale je oproti IB druha liga.
Tak jsem si to po sobe precetl, no pani lingviste snad prominou... ;-))

Termín "druhá liga" jsem použil s ohledem na zmíněné high-end aplikace, extrémní zátěže a high availability, tedy oblast, kde je doma Oracle (a DB/2). Tam MS SQL těmto dvěma prostě konkurovat nemůže. Jinak je samozřejmě pravda, že existují aplikace, kde je nejlepší volbou MS SQL, stejně jako exitují aplikace, kde je nejlepší volbou MySQL.

Me se ta analogie s ligou proste nelibi. RDBMS je RDBMS, nekdy lepsi, jindy horsi. Kvalitu muze posoudit kazdy sam. Jsou situace, kdy DB/2 nebo Oracle nasadit proste nelze. Samozrejme se ale priklanimk nazoru, ze MS SQL je draha a ne moc kvalitni RDBMS, navic nedostupna pro Linux.

Tak ještě jednou, asi mám problém vyjádřit se srozumitelně. Označení "druhá liga" se netýkalo jakési abstraktní "kvality", ale výhradně schopnosti zvládat extrémní zátěže. Tedy přesně toho, čeho se týkal původní příspěvek. Na systém, kde má databáze pár MB a transakce se počítají v jednotkách za minutu, se samozřejmě Oracle ani DB/2 nehodí - jenže o tom tu řeč nebyla. Doufám, že už je to jasnější a že to nebude potřeba opakovat potřetí.

z Vaseho e-mailu je videt, ze jste jeden z tech informatiku, kteri se pohybuji v prostredi "skutecnych" inzenyru (ve vasem pripade stavaru). Prekvapuje me, ze ta aura toho skutecneho inzenyrstvi nepronika i na katerdu informatiky (ci jak se jmenuje). Vzdyt jsou okolo lide, kteri perfektne vedi co je modularita, interface, objekt. A kdyz opustite svou kancelar, tak muzete sledovat , ze 90 % cinnosti tech skutecnych inzenyru je rutinni cinnost. Jak to, ze se nasnazite tyto tisicilete zkusenosti aplikovat v informatice. Okolo Vas se to dnes a denne praktikuje. A vas navrh je, jit na to mnozstvi programu, ktere jsou zapotrebi vzdycky s "projektem". Projekt, ve kterem se ti nejschopnejsi zamysli pokud mozno nad vsemi detaily nejakeho problemu, aby pozdeji zjistili , ze prece jen nemysleli na vsechno - samozrejme pote, kdy je "to vsechno" jiz zabetonovano v databazovem navrhu - nejake konkretni databaze (smula je, ze potecialni zakaznik ma jiz jinou v provozu). *velky udiv*

Jestli to bylo na mne, tak jsem zrovna z katedry inzenyrske informatiky. Myslim, ze tusim co je interfacem a modularita. Prave, ze se sikovne navrhne framework, tak je vam jedno jestli vzadu je db2, PostgreSQL, MySQL nebo Oracle. Co uberete na aplikacni urovni to pridate na urovni databaze a naopak. Podstatne je, ze zmeny se nesiri dale v kodu. Melo by byt samozrejma, ze kdyz vyvyjite aplikaci, tak se zamyslite nad prenositelnosti - a dobre navrzena aplikace asi i bude dobre prenositelna. Setkal jsem se ale s programatorem, pro kteryho prenositelnost bylo tabu. Dalo mi celkem praci ho presvedcit, ze neni nic jednodussiho, nez si proste zkusit kod na Oraclu a pak na MSSQL. Zmeny na aplikacni urovni byly minimalni, a vysledek snad o neco lepsi.

"... popisovat na rootu autoconf kompilaci a instalaci, to je házením hrachu o zeď."

Tak tomuto neviem ci nerozumiem preto ze som zo Slovenska, ale u nas "hadzat hrach o stenu" znamena robit nieco zbytocne, nezmyselne, pretoze ten komu to robime (hovorime) to neurobi, neposluchne, nepouzije.

Nehodilo by sa do tej vety viac "nosit drevo do lesa" alebo nieco podobne, teda nieco s vyznamom robit nieco, co je nadbytocne?

Ja len tak, ci si to mysli aj niekto iny, alebo ja zle rozumiem.

ja myslim, ze jste si sam odpovedel:
..."hadzat hrach o stenu" znamena robit nieco zbytocne...
ale "nosit drivi do lesa" je nepochybne mnohem trefnejsi pro tento pripad

...lingviste jedni... ;-]

tak to je opravdu hezký příklad vytržení z kontextu :-)))

v pův. příspěvku se píše "znamena robit nieco zbytocne, nezmyselne, pretoze ...", přičemž ono "pretože" tam dělá právě tem významový rozdíl, který přirovnání, o něž jde, činí nevhodným, a vy to oříznete a konstatujete "sám jste si odpověděl" :-)))

skoro jako diskuse našich politiků :-)))

tedy ne že by na tom záleželo ...

Rad by som uviedol svoje skusenosti s pouzitim free databaz pre slovenske prostredie, t.j. znakove sady ISO8859-2 a Win1250, a samozrejme spravne triedenie (collation).

Testovali sme vo firme len tie DB ktore je mozne nasadit aj pod Win 2000. Takze sorry ale PostgreSQL vypadol. Zostali nam MySQL, SAP DB, Firebird.

SAP DB bola absolutne nepouzitelna.

MySQL sice umoznuje nastavit charset "czech" ale ked zacnete pouzivat prikazy ORDER BY a LIMIT sucasne tak triedenie zblbne. V manuali je uvedena velmi divna optimalizacia, ktorej vobec nerozumiem ako moze spravne fungovat, http://www.mysql.com/doc/en/LIMIT_optimisation.html

Firebird vysiel ako vitaz. Zatial sme nezistili ziadne problemy so slovencinou. Navyse je prima ze sa da charset a collation nastavit pre kazde pole tabulky individualne. Idealna DB pre viacjazycne webove aplikacie. Skusali sme zatial iba PHP a ciatocne JDBC.

Pre upresnenie: Jedna sa o mozne lokalizovanie nemeckej aplikacie urcenej pre intranet. Projekt je len vo faze navrhov zmien a odhadov. Povodne nemecke riesenie je na baze PHP a MySQL.

A posledna poznamka. Kniha od pana Cisare je skutocne spica, bomba, super kseft.

MySQL tridit cesky umi, staci jen nastavit char_set = win1250 - pro windowsy. S CZECH mi to taky nefungovalo. PostgreSQL jde nainstalovat pod windows celkem jednoduse.
ftp://209.61.187.152/postgres/postgres_beta4.zip


By

1. ten link nefacha

2. I kdyby fungoval, nemyslite, ze zajemce o PgSQL pod Win si nejdrive radsi precetl nejaky dokument, nez bude rovnou stahovat instalaci?

Ja pouzivam PostgreSQL pod win pomoci Cygwinu, na testovani je to celkem dobre, ale produkcni system bych na tom teda fakt nepostavil.

Taky jsem zkoušel PostgreSQL v podání CygWin a pochopil, že na Windows běží. Běží to sice přijatelně, ale až příliš z toho čisí emulace Unixu, a to nejen samotným CygWin, ale mnoha dalšími věcmi. Působilo to na mě dost neuspořádaně. Nepůsobilo to celé na mě moc dobře, a tak ani já bych se neodvážil PostgreSQL pod Windows nějak propagovat.

Kdysi jsem se o tom bavil, a prý je databáze tak silně psaná pro Unix, že už jí někdo pro Windows upravovat nechce, a nikdo do jádra nechce zasahovat.

Vnitrnosti obou platforem se natolik lisi, ze pokud s tim nepocitate od zacatku, tak potom nativni port je dost problem a proto je tu Cygwin - portovaci vrstva pro portovani Unix veci na Win, nic min, nic vic. Simuluje UNIX api pomoci nativnich Win api aby kompilace Unixovych aplikaci pod win byla co nejsnazsi, cimz umoznuje provoz spousty aplikaci jejich netivni win port by nejspis nikdy nebyl realizovan, me se velmi libi treba uz jen proto, ze prinasi drtivou silu shelu + klasickych unixovych utilit do windows (i kdyz afaik zde zrovna ty nativni porty existuji) tj. je to proste vlastonost PostgreSQL a jeji nasazeni pod win asi nelze doporucit (muzeme-li se rozhodovat bez zateze z minulosti), ale pod Linuxem je snim treba pocitat, kazdopadne podle toho co zde zanelo Firebird urcite stoji za pozornost

Koho zaujima ci bezi PostgreSQL na oknach??
Databazovy server je predsa krabica rozmeru mensej pracky niekde v kute v pivnici....
Bezi na nej asi volajaky system, ale to asi zaujima len toho, kto sa stara o zalohovanie dat.
Pre ostatnych je to BLACKBOX ku ktoremu pristupuju cez rozne rozhrania.
Ze zakaznik chce mat Win2K a IIS (alebo apache) a MySQL na jednom stroji???
To poznam. Na jednom stroji vsetko (firewall, router, proxy, dns, dhcp, mail, http, ftp, fileserver, prinserver, faxserver, ldap, webdav....). Kde je bezpecnost?? Stabilita?? Jedna chyba v skripte (asp, php, cgi, hocico) zlikviduje celu firmu.

A, zase jeden pan maximalista, ktery si mysli, ze databaze jsou pouze pro velke informacni systemy...

Pane, takova databaze je uzitecna pro vetsinu aplikaci a dokazu si docela dobre predstavit, ze bych mel aplikaci pro jednoho uzivatele s jednim databazovym serverem na jednom pocitaci. Treba i bez site. I tak se obcas provozuji aplikace, verte mi...

Pokazde to neni o kvantu transakci, ale treba i o malych aplikacich, kde se databazova zatezuje jen malo. Neni pak vubec duvod pridavat k server ve velikosti pracky...

no zda se ze tam to Postgre neni :-)

To cesky trideni nebude tak horky...

Mam pocit, ze jsem se asi pred rokem pokousel cesky tridit s binarkou MySQL, ale spatne to tridilo pismenko 'CH', po nekolikahodinovem studiu manualu jsem se docetl, ze to musim rekompilovat s volbou czech, pak to tridilo spravne.

Jen tak na okraj, nebo uz to tridi 'CH' defaultne dobre?

MySQL a triedenie
-----------------
Nejedná sa len o "CH" ale aj o ď,ť,ň,ľ,ĺ,ô atď. Skúste si vytvoriť jednoduchú tabuľku osôb, vložiť aspoň 20 záznamov (nielen Pepa Novák ale aj Ľubomír Hĺbavý) a potom spustiť napr. takéto stránkovanie (bežná prax webovej aplikácie):

SELECT firstName, lastName FROM person ORDER BY lastName LIMIT 10,5

Pochybujem, že Vám to bude správne fungovať.

Pozn.: MySQL 4.0.12, charset czech, OS Win2k, IIS 5, PHP 4.3

NEKOMERCNI NATIVNI PODPORA PRO WIN

http://momjian.postgresql.org/main/writings/pgsql/win32.html

Je to všetko pekné, ale pochopte priatelia, ako by sa asi zatváril šéf, keby som mu mal ukázať takúto inštaláciu. Sám som si vyskúšal PgSQL rozchodiť pomocou Cygwin. Bolo to strašné trápenie a nakoniec som tak ako tak nedokázal rozchodiť slovenčinu v PgSQL na anglických Win2k.

Ešte jedna úvaha. Ja som spomínal, že sa jedná o intranetovú aplikáciu. Podľa mojich skúseností asi 90% malých a stredných firiem prevádzkuje sieť na Windowsoch. A aby bol bežný administrátor schopný ten intranet rozchodiť tak musí mať user friendly inštalačky. Myslím, že nasledovné 2 kombinácie sa ľahko inštalujú:

1. Win2k, IIS, PHP, Firebird
2. Win2k, Tomcat, Firebird + JDBC

A samozrejme stačí Win2k a IIS vymeniť za Linux a Apache, a máme relatívne multiplatformový soft. Možno by to šlo aj s Mac OS X. Čo vy na to?

Omlouvam se za nefunkcni odkaz na PostgreSQL, ale nemel jsem cas to hledat v google a toto jsem nasel v readme u win instalace.

MySQL me tridi cesky KROME "CH". Ale musim pouzit char_set win1250, jinak to nejde - nikoli CZECH.

Hodne stesti

Tak to mate pravdu, s charsetem win1250 to skutecne dela to co jsem popsal.

Ale jinak to jde! ;-) Prectete si manual... Ale musite rekompilovat, ta volba je myslim CZECH....

FredBrede a Izape,

Bohužiaľ nemôžem s Vami súhlasiť. Ani jedno nastavenie MySQL charsetu CZECH (resp. WIN1250) netriedi správne pri použití už uvedeného príkladu:

SELECT ... FROM ... ORDER BY ... LIMIT offset, page_size;

Opakujem naposledy: Aj keď nastavenie CZECH triedi správne CH a diakritiku, tak zblbne pri použití LIMIT !!! Napr. slová začínajúce na "á" sa ocitnú na konci. Ak nepoužijete LIMIT, tak to triedi správne !? Je to bug v MySQL 4.0.x, tabulky typu ISAM.

Môžeme si vymeniť demo data ak neveríte.

Tak vidíte ono to navíc blbne, s limitem sice ve firmě pracujeme, ale tabulky máme již setříděné (data se generují jednou za měsíc a to dávkově).

Chtěl jsem jen poukázat na to, že CZECH (WIN1250) netřídí písmenko "ch". Je nutná kompilace a ještě je tam chyba.

Prominte ze vstupuji do diskuskuse, kdyz si proti vam pripadam jako amater, ale po precteni prispevku o prenositelnosti ci neprenostelnosti a vhodnosti DB, tak proste musim.
Existuji prece minimalne dve situace kdy se rozhoduje o tom na cem to pojede. Pokud vyvijim tzv. specialni aplikaci pro jednoho zakaznika, tak mam bud danou db nebo si ji zvolim podle potreb aplikace. A pokud delam aplikace ktera se bude prodavat X zakaznikum (a neni to zrovna pouhy seznam dat) tak musim pocitat s tim ze tech db bude proste vic a ruznych. Mohu sice nastavit ruzna omezeni na cem jsem to schopen odladit, ale vysledek je stejny: pokud to pojede jenom na jedne, tak mne s tim tak kde uz maji koupenou (nebo jinak ziskanou ) jinou db VYHODI.
Co se tyka kvalit jednotlivych db, tak si myslim ze diskuse je celkem o nicem pokud porovnavate neporovnatelne.

Pokiaľ programujete v Jave a skutočne objektovo, tak by ste mal vedieť čosi o ORM = Object Relational Mapping. Odporúčam pozrieť štandard JDO, resp. "neštandardné" open-source projekty Hibernate a iBATIS. Umožnia vám znížiť náklady pri programovaní prenositeľnosti na viacero DB.

http://www.hibernate.org
http://www.ibatis.com
http://www.jdocentral.com/

To co jste napsal je svata pravda. Ta debata se vede asi o necem jinem. Zda-li mam pouzivat jen ty vlastnosti SQL, ktere jsou podporovany vsude (a co chybi osetruji na aplikacni urovni) nebo zda-pouzivam i ty ne vsemi podporovane vlastnosti (mohu mit jednodussi aplikacni uroven, ale n databazovych vrstev)

Súhlasím.

Pozrite si iBATIS. Umožní Vám použiť všetky špeciality danej DB.

Uvediem príklad Oracle vs. MS SQL. V MS SQL použijem autoincrement a v Oracli sequence generátor. Taktiež môžem použiť na mieru šitú storovanú procedúru.

iBATIS mi umožní v Jave napísať jednoduchú metódu v business logike, napr. "Personnel.getStupidManagers()". Pritom len správne nakonfigurujem ORM engine iBATIS tak aby pri volaní tejto metódy zavolal napr. storovanú proc v Oracli, ale pri nakonfigurovaní MS SQL to môže byť view. Krásne je to, že vrstva business logiky nevie nič o tom aká DB je momentálne použitá.

Otázkou je, nakolik to zpomalí práci s databází a hlavně, zda-li to neomezuje využít všechny vlastnosti dané databáze. Každá architektura je v nečem jiná, lepší, viz. například práve MGA u Firebirdu/PostgreSQL.

Já jsem zkoušel hibernate na tlustém klientovi, nahrával jsem z dat líný strom a dával to do komponenty JTree. Všechno bylo katastrofálně pomalé a aplikace se spouštěla snad 10 vteřin. S čistým JDBC to bylo 3x rychlejší. Jen jsem to sice zkoušel, ale indexy jsem měl nastavené správně...

Který ORB je nejlepší na tlusté klienty a vůbec, má cenu používat JDO a podobné technologie mimo webové a EE servery?

Máte čiastočne pravdu. Ale keď zvládnete nastavenia zvoleného ORM, tak pokles výkonu bude pravdepodobne minimálny.

Autor Hibernate (Gavin King) vypísal odmenu tomu, kto mu dokáže, že použitie Hibernate je pomalšie viac ako o 10% oproti priamemu JDBC. Skúste mu poslať váš príklad.

Ja robím momentálne len webové aplikácie (tenký klient). ORM nasadím len vtedy, keď zákazník požaduje možnosť prechodu na inú DB v blízkej budúcnosti. Ale inak som stále zástancom viacvrstvovej architektúry, takže napr. vzor DAO používam bežne.

PS: Skúste si pozrieť iBATIS. Možno vás presvedčí viac ako Hibernate. Má skvelý DAO Manager. Vyskúšal som ho aj s Hibernate, ale momentálne používam technológie iBATIS (DAO Manager + SQL Mapper).

Pratele,
instaloval nekdo z vas jiz FB 1.5 na win (uspesne)? Vicemene neznam (tedy spise znam mene nez vice) DB Interbase ani FireBird. Kdyz si stahnu instalaci FireBird 0.9x ve forme setup.exe (instalacni skript z interbase 6.0) a nainstaluji, bezi vse v poradku a dokonce i funguji utilitky na interbase - mam na mysli pripojeni primo na local, nikoli pres tcp/ip.

U FireBird 1.5 jsem ale takovyto instalacni soubor nenasel - jen zabaleny adresar. Po rozbaleni a zaregistrovani i sluzeb DB bezi. Lze na ni pristupovat vzdalene (localne) pres tcp/ip ale nemohu si ji v zadne utilitce pripojit localne. Navic se mi nepodarilo zalozit zadneho uzivatele - pres ruzne utilitky (predpokladam ze to bude souviset se zmenou nazvu db uzivatelu) a ze jsem jich zkusil nekolik. Navic se mi nepovedlo zprovoznit ani ODBC pripojeni :(

Jestlize neprovedu instalaci FireBirdu 0.9x (i s engine Borlandu) nektere utilitky nejdou ani spustit.

Celkem dlouho jsem prohledaval web a nejaky rozumny postup jsem nenasel.

Mate nekdo nejakou lepsi zkusenost?

Diky

PS: Utiliky - programky ruzneho puvodu na spravu ruznych casti DB (tabulky, uzivatele, replikace, ...)

Tak za prve:

Stahnete si verzi 1.0.X (EXE), v pohode to funguje.

2) BDE musite sehnat zvlast, ale nevim na co. Je to takovy siditko, komunikujte primo se serverem.

3) Verze 1.5 jeste stale *bohuzel* nevysla, takze binarky jsou k dispozici zatim v ZIPu. Jakmile to vyjde, pak si budete moci stahnout instalator. Muzete si ale i tak Firebird nainstalovat. Viz readme.txt...

Mám notebook HP nx9005. Nainstaloval jsem si na něj (krom standartně dodávaných Billových XP) Linux Mandrake 9.1. Problém je, že notebook jede pořád nanaplno a ani se nedá zobrazit stav baterie v Gkrellm-u. Pokoušel jsem se to řešit prekladem jádra (resp. ho za mě překládal člověk, který tomu rozumí mnohem více než já) a vyskytly se problémy s jeho instalací. Jen chci dodat, že v BIOSU nemám možnost nastavit nic ohledně baterie...
Prosím o jakoukoliv radu, jak vyřešit můj problém - ať už v Mandraku, nebo i jiné distribuci Linuxu - pokud by to v ní šlo snadněji.
Díky Meli

Pod FB v1 pracuji jiz pres pul roku, ale az ted jsem se dostal na root. Kazdopadne bych chtel rici, ze co se tyce databazovych moznosti FB mne FB velmi nadchl. Velmi sikovne jsou UP jako view. V clanku se hovori, o UDF. V dobe, kdy jsem zacinal na IB neexistovala napr. funkce UPPER pro ceske znaky. Pomoci UDF jsem byl schopen tuto doplnit. V kombinaci s UP lze vytvorit pseudo tabulku ktera ma zdroj v alokovane pameti FB. To me pripada velmi dobre.
Dale musim rici, ze co se tyce konzistence dat a spolehlivosti, je velmi dobra. Zatim nedoslo k zadne ztrate dat ani poskozeni jejich integrity.

To je asi vse

Petr Laf

Jak importujete data z Excelu/Accessu do Firebirdu?

Nemohu najit bezplatny SQL administrator pro Firebird, ktery by zvladal import z Excelu a Accessu.

Z tech komercnich, ktere to umi, se mi nejlepsi jevi IB manager, ale nez pozadam jeho koupeni, rad bych mel par referenci, ze se nemylim v dobrem mineni o jeho kvalitach.

Caute,

snazim sa urobit instalacny script, ktory mi povytvara tabulky userov, atd... a potrebujem z neho zavolat dalsi script.

Ako na to?

Diky.

Majte sa,
Andrej.