Hlavní navigace

Názory k článku
MySQL vs PostgreSQL vs Firebird

Honza (Jerry) Jaroš
25. 10. 2005 0:34 Nový

"Existuje už aj verzia pre Linux"

celé vlákno

Jenom poznámka k tomu tvrzení, že u Firebirdu "Existuje už aj verzia pre Linux":

Firebird, původně Interbase a ještě původněji Jrd byla koncem sedmdesátých let nejprve implementována "pro počítače Apollo, VAX, PDP a HP, a v prostředí operačního systému VMS a UNIXových systémů jako je HP-UX, Solaris nebo AIX" (citát z knihy Podrobná příručka InterBase/Firebird). Na Windows - a také NetWare a Linux - byl přenesen až později Borlandem poté, co tuto databázi v roce 1989 koupil od původního autora Jima Starkeyho. Podle zmíněné knihy byla InterBase vůbec první komerční databází přenesenou na Linux. Firebird, který vznikl po uvolnění kódů InterBase 6.0 v roce 2000, byl tudíž od začátku vyvíjen jako multiplatformní databáze běžící mj. i na Linuxu.

MS Windows tudíž rozhodně není primární platforma, na níž by Firebird běžel.

Co se týče samotného testu, řekl bych, že testování rychlosti načítání jedné tabulky je od standardního nasazení docela vzdálené a jeho vypovídací hodnota je docela malá. Škoda. :-/

Michal Kubeček
Michal Kubeček (neregistrovaný)
25. 10. 2005 21:09 Nový

Re: "Existuje už aj verzia pre Linux"

celé vlákno

Upřesnění: Jim Starkey prodal InterBase (i se svou firmou) nejprve Ashton-Tate (ano, dBase), Borland posléze koupil celou Ashton-Tate i s InterBase.

MS Windows tudíž rozhodně není primární platforma, na níž by Firebird běžel.

Podle toho, co vídám v firebird-devel listu, bych řekl, že v současné době je win32 primární platformou podstatné části vývojového týmu.

Honza (Jerry) Jaroš
25. 10. 2005 21:18 Nový

Re: "Existuje už aj verzia pre Linux"

celé vlákno
Díky za upřesnění upřesnění...;-)
Michal Molhanec aura:100
25. 10. 2005 0:54 Nový

která lama?!?

celé vlákno
testovat MySQL a nenapsat použitý typ tabulky... děkujeme odejtěte... Na meranie som použil nasledovný PHP skript. Nic nevidim :-(
Jan Sunavec
Jan Sunavec (neregistrovaný)
25. 10. 2005 9:56 Nový

Re: která lama?!?

celé vlákno
defaultne nastavenie pre MySQL je MyISAM.
Michal Molhanec aura:100
25. 10. 2005 11:43 Nový

Re: která lama?!?

celé vlákno
to nevim, me to defaultne vytvari innodb. ale chapu to tak, ze v testu byl pouzit myisam.

jinak php skript uz vidim, ale je v nem dvakrat pouziti postgresql a naopak ani jednou firebird
Miroslav Suchý aura:87
25. 10. 2005 15:09 Nový

Re: která lama?!?

celé vlákno
benzin
benzin (neregistrovaný)
25. 10. 2005 1:12 Nový

Chyby v mereni

celé vlákno
Par chyb a nedostatku
1) Neuvadite verze MySQL a FireBirdu (mezi 1.0, 1.5 a 2.0 jsou jiste vykonostni problemy)
2) Na import dat do Firebirda existuji nastroje, popripade primy pristup k radku db (hodne to urychluje).
3) Provest test nad nevyvazenymi indexy (postupne mazat a pridavat zaznamy, az se indexy rozbiji), mozna Firebird strati dech.
4) Provest test nad hodne menenou databazi (Firebird, zaznamy nemaze, ani neupravuje, vzdy vytvori novy a i se zmenou, takze se zaznamy postupne hromadi).
5) Provest test rychlosti s primym pristupem k tabulkam.
6) Provest test rychlosti, alespon s nejakymi agregacemi (alespon zakladnimi).
7) Otestovat rychlost advancet technologii: vnorenych selectu, kurzoru, pohledu, uloznych procedur, spojovani tabulek s vytvorenymi cizimy klicema.

Je mi jasne, ze autor se snazil provest testy kompletni, ale bohuzel neni. Jsem presvedcen, ze nap. pri vyuziti FK (Foreign Key), by PostgrSQL dosahl vyrzne lepsich vysledku nez MySQL (ktery je nemaji).

P.S.: Free nastroje na udrzbu FireBirda najdete primo na http://firebird.sourceforge.net/. FlameRobin a IBExpert. (Vetsina nastroju pro InterBase funguje i pro FireBird).
benzin
benzin (neregistrovaný)
25. 10. 2005 1:16 Nový

Re: Chyby v mereni

celé vlákno
Omlouvam se, uvedeni cisel DB, jsem prehledl, samozrejme v clanku je. Btw. jiz existuje MySQL 5.
rezna
rezna (neregistrovaný)
25. 10. 2005 11:17 Nový

Re: Chyby v mereni

celé vlákno
presne tak proc se testuje pgsql 8.1 beta ale beta (dnes uz i RC) MySQL 5 je ignorovana.

jinak ten benchmark je fakt o nicem - testovat vykonnost by to chtelo tak na inner/left joinech aspon 20 tabulek kde kazda tabulka ma aspon 5k radku - proste takove minimalni bezne zatizeni vetsi aplikace.

delat benchmark pro mini aplikace a mini DB nema smysl.

navic benchmark delany pomoci PHP se mi nelibi - zavisi hodne na rychlosti extension pro danou DB - chtelo by to benchmark primo z konzoli danych DB. navic by taky neskodilo porovnani proti oracle a mssql ;)
Pepa
Pepa (neregistrovaný)
26. 10. 2005 9:10 Nový

Re: Chyby v mereni

celé vlákno
Ha ha ha, toho databázového architekta bych vyhodil. Joinovat 20 tabulek ....
rezna
rezna (neregistrovaný)
26. 10. 2005 9:23 Nový

Re: Chyby v mereni

celé vlákno
ja nevim co Ti/Vam na tom zda divneho. nase hlavni firemni aplikace obsahuje neco pres 100 tabulek a pri dotazech do ni je to bezne join aspon 10 tabulek aby clovek dostal to co potrebuje takze mi na tom nic divneho neprijde - precijenom neni to blbej pubertalni chat ;)
send flower
send flower (neregistrovaný)
26. 10. 2005 11:17 Nový

Re: Chyby v mereni

celé vlákno
Presne tak, pokud je projekt velkej, musi se tabulky spojovat, jinak by to bylo zatracene neefektivni ukladani.. Jeho vykrik mi pripada jako vykrik u cloveka co delal akorat DB na svuj web v mysql a dal to do jedny tabulky, ale treba se pletu.. :)
Filo
Filo (neregistrovaný)
26. 10. 2005 15:27 Nový

Re: Chyby v mereni

celé vlákno
Otazkou je, zda ma smysl hledet pri dnesnich velikostech HDD na nejakou efektivitu ukladani nebo na to, aby select probehl co nejdrive. Osobne preferuji druhou moznost, protoze zakaznika absolutne nezajima, jak jsou udelana streva, ale jak se cela aplikace chova a 'vo tom to je' ;)
zz
zz (neregistrovaný)
27. 10. 2005 21:05 Nový

Re: Chyby v mereni

celé vlákno
to je pekne ale skusal si taky projekt expandovat o nove funkcie a zdroje dat? asi nie. V kancli sedim este z kamosom kazdy mame ini pristup ja mam vecsie mnozstvo tabuliek viacmenej mam tabulky na co najmensie casty a vsetko poprepajane klucmy. kamos robi co najvedsie tabulky aby to mal hned.

ja mam aplykaciu ktoru robim stale komplexnejsiu nad jednou DB a on je vdaka nie najlepsiemu navrhu buduje stale nove a nove DB a aplykacie mu chodia do viacerych DB naraz a z kazdej potom vytahuje z 20 stlpcovej tabulky 3 stlpce alwebo ma cast zaznamov duplicitnych v roznych DB fakt radost nieco nove dorobit.

troska vela roboty na DB kde mavame maximalne stovky zaznamov.
9x0
9x0 (neregistrovaný)
2. 11. 2005 0:02 Nový

Re: Chyby v mereni

celé vlákno
Po precitani vasho prispevku som sa utvrdil v tom, ze tie ciarky a gramatika sa predsa obcas hodia. Chcelo by to zamysliet sa nad tym ;-)
hh1584752
hh1584752 (neregistrovaný)
15. 5. 2006 9:47 Nový

Re: Chyby v mereni

celé vlákno
podla Vasej gramatiky je skvelou spravou uz len to, ze k vypoctovej technike maju pristup uz aj neandrtalci :-D
NB
NB (neregistrovaný)
30. 12. 2006 11:49 Nový

Re: Chyby v mereni

celé vlákno
Ako napriklad ty :D :D
earl365
earl365 (neregistrovaný)
25. 10. 2005 8:09 Nový

Re: Chyby v mereni

celé vlákno
Agregacie:

Svojho casu som skusal rychlost PostgreSQL 8 a firebirda 1.5.2. Mal som tabulku, cca 90000 zaznamov + vytvoreny view s troma agregaciami (nejake county). Potom som robil selecty na tomto pohlade, ale zotriedene podla tych agregacii (take boli poziadavky) Na mojom pocitaci trval jeden select na PostgreSQL cca 22 sekund, kym na Firebirde asi 4-5. Takze je tam rozdiel. A velky.
Na druhej strane vie PostgreSQL veci, ktore Firebird nie (minimalne vo verzi 1.5.2). Napr. inline view.
P.L.
P.L. (neregistrovaný)
25. 10. 2005 11:09 Nový

Re: Chyby v mereni

celé vlákno
Problem bude mozna v tom, ze postgres neprovadi optimalizaci agregacnich funkci (existuje jeden rozsiritelny framework, ktery je pouzit i pro count()). Nektere databaze count dovedou optimalizovat (pomoci indexu a pod).
Mozna ze by vysledky vypadaly uplne jinak u jine agregacni funkce ... ale to v realne aplikaci moc nepomuze ;-)
Jakub Hegenbart aura:84
26. 10. 2005 3:17 Nový

Re: Chyby v mereni

celé vlákno
Firebird kvůli MGA dělá při \"select count()\" table scan s kontrolou verzí. Asi tak. ;-)
misch
misch (neregistrovaný)
25. 10. 2005 8:46 Nový

Re: Chyby v mereni

celé vlákno
Provest test nad nevyvazenymi indexy (postupne mazat a pridavat zaznamy, az se indexy rozbiji), mozna Firebird strati dech.
To ale odpovídá běžnému nasazení, ne? Málokdo neustále reindexuje celou databázi.
zz
zz (neregistrovaný)
27. 10. 2005 21:08 Nový

Re: Chyby v mereni

celé vlákno
no pokial mas v DB zaznamy z radiusu tak napr v postgreSQL je VACUUM a ANALYZE to prve co das do cronu a minimalne raz tyzdenne (velmy maly provider) inak ti zacnu casy odpovedy z DB ras exponencialne.
uživatel si přál zůstat v anonymitě
25. 10. 2005 9:30 Nový

Re: Chyby v mereni

celé vlákno
ad 4)

hmm, pocul ste niekedy o transakciach?
tento pristup pouziva i postgresql, ono sa vam totiz moze stat, v jednom okamihu moze mat kazda transakcia svoju vlastnu kopiu riadku (ci az vsetkych riadkov) danej tabulky. (a to je vlastne hlavny dovod, preco existuje vacuum)



btw, ako je na tom emulator databazy (mysql) v pripade, ze tabulka je vacsia ako velkost pamate? este stale ma problemy?
Pichi aura:74
25. 10. 2005 11:48 Nový

Re: Chyby v mereni

celé vlákno
Srandisto. Neudělal jsi překlep? Mýsto mysql jsi pravděpodobně chtěl napsat mssql, ne? S tímhle mysql žádné problémy nemá.
uživatel si přál zůstat v anonymitě
25. 10. 2005 13:13 Nový

Re: Chyby v mereni

celé vlákno
nie, neudelal.

mal som nasadene mysql a vzdy, ked velkost tabulky presiahla velkost fyzickej pamate, CPU slo na 99% a niekolko sekundove requesty. pridanim pamate sa problem vyriesil.

nakoniec som premigroval na postgresql, tabulka ma momentalne 20GB a server ani nevie, ze nejake selekty robim.

a co sa tyka mssql, nasiel som uplatnenie aj pren, skutocne vyborna podlozka pod hrncek s cajom :-)))
Michal Molhanec aura:100
25. 10. 2005 13:19 Nový

Re: Chyby v mereni

celé vlákno
to jste musel delat neco blbe, ve stylu buffered/unbuffered query
uživatel si přál zůstat v anonymitě
25. 10. 2005 15:23 Nový

Re: Chyby v mereni

celé vlákno
jj, nieco blbe som urobil, pouzil som mysql.

prikaz bol vykonany z konzoly (program mysql), jeho vystupom malo byt mizive promile (10 z 10M) riadkov.

jediny problem co som zistil bol v tom, ze index bol na celu tabulku (v mysql akosi neboli partial indexy).

a klinec do rakvy zarazil pripad:
select * from table where status > 1;
id | status
-----------
1 | 1

!!!


jednoducho mysql neprekrocilo tien php ... bordel, nefunkcnost, nestabilita.
Michal Molhanec aura:100
25. 10. 2005 15:34 Nový

Re: Chyby v mereni

celé vlákno
IMHO blbost
Dusan
Dusan (neregistrovaný)
25. 10. 2005 17:22 Nový

Re: Chyby v mereni

celé vlákno
Este jednu o cervenej ciapocke. Tazko zvalovat chybu v konfiguracii, ci navrhu databazy na mysql.
Nemam najmensi problem ani s 14GB databazou na 512MB / 4xPentiumPro200MHz.
uživatel si přál zůstat v anonymitě
25. 10. 2005 17:38 Nový

Re: Chyby v mereni

celé vlákno
hmm, nevravim o databaze, ale o tabulke.
je pravda, bolo to pred 4-mi rokmi, bolo to myisam.

a chyba navrhu?
ak jeden navrh sposobi zablokovanie stroja pri mysql a postgresql nie, chyba bude inde. nebol to jediny system, kde som sa s podobnou situaciou stretol (a pravda, stretol som sa aj s tym, ze to nezablokovalo). ci to bolo indexami alebo strukturou dat, nezistoval som.

poviem to asi takto ... ak niekto odomna chce mysql, nasleduje odhovaranie, ak je neuspesne, tak zdvojnasobenie sumy s podpisom dohody o vzdani sa naroku na zaruku
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 18:59 Nový

Re: Chyby v mereni

celé vlákno
Já se přiznám, že za léta používání MySQL jsem se s ničím podobným nesetkal. Já koukám na MySQL jako na hloupoučkou, ořezanou databázi, která je ale spolehlivá, multiplatformní, dobře pracuje s thready a je dobře zdokumentovaná. Ještě nikdy se mi nestalo, že by mi MySQL udělala nějaký skutečný průšvih. Pravda je, že raději dělám s lépe vybavenými databázemi, než je MySQL, ale často jsem nucen na nich něco postavit.

Žádná databáze nebude úplně bez vroubku. Stačí si přečíst libovolný seznam chyb k libovolné databázi, pokud je tedy vývojáři zveřejňují. Nicméně myslím si, že hlavní problém bude v tom, že "nezistoval som", kde je problém. Na 99% bývá problém mezi klávesnicí a židlí, spíše, než v databázi.

Ona každá databáze chce svoje a chce trochu péči. Když mě teď posadíte k PostgreSQL, se kterou jsem skoro nikdy nedělal, tak vám pravděpodobně udělám podobná zvěrstva a bez dostatku sebereflexe dojdu k závěru, že PostgreSQL je neschopná databáze a budu od zákazníků vyžadovat zdvojnásobení sumy a vzdání se nároku na záruku.
benzin
benzin (neregistrovaný)
25. 10. 2005 19:19 Nový

Re: Chyby v mereni

celé vlákno
No nemate tak zcela pravdu. To ze ruzne databaze zvladaji ruznou zatez ruzne, je preci jasne. Musite se prispusobit. Teoreticky jde sice ten samy SQL dotaz nasadit na vice databazi, ale prakticky je vhodnejsi upravit konstrukci pro kazdy dany db stroj.

Jinak s tim nerucenim za MySQL s Vami souhlasim. MySQL nezvlada omezeni, ani FK ani trigery. Pak se spatne zajistuje konzistence dat. (Tedy nevim jak verze 5, jestli tohle jiz zvlada)

Add. MsSQL, musim rict, ze mne svou rychlosti velmi prijemne prekvapila. Ale nerozhodl bych se pro ni, existuji databaze zadarmo a pokud potrebuji opravdu dobry vykon, pak jedine Oracle.
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 21:47 Nový

Re: Chyby v mereni

celé vlákno
Souhlasím s tím, že MySQL toho umí dost málo, a že se daleko lépe dělá s mnohými jinými databázemi. Nicméně FK bez problémů zvládají už hodně staré verze řadu let nazpátek.
Pavel Janoušek aura:43
5. 12. 2005 14:11 Nový

Re: Chyby v mereni

celé vlákno
Z pozice vyvojare bych MsSQL vytkl jednu podstatnou vec a sice naprosto mizerny JDBC ovladac, navic dokumentace k nemu mi pripada jako by reflektovala zcela jiny produkt. Nastesti mame jTDS...
Dusan
Dusan (neregistrovaný)
25. 10. 2005 20:22 Nový

Re: Chyby v mereni

celé vlákno
Upresnenie - ja som sice vravel o 14GB DB, ale pozrel som si prave aktualny stav. Velkost DB : 15.5GB a najvacsia tabulka je 76mil. zaznamov = 14GB data + 1GB indexy :-)
Fero
Fero (neregistrovaný)
26. 10. 2005 6:40 Nový

Re: Chyby v mereni

celé vlákno
Heh, borec co si nevie ani len MySQL nainstalovat, nakonfigurovat a spravne pouzivat. Zaujimave, ze vsetkym to spolahlivo funguje, len jeden expert musi odhovarat a vymyslat dohody o vzdani sa zaruky :))

Doporucit klientovi Oracle bude to spravne riesenie. Za licenciu zaplati $40k a za aplikaciu $4k. Tomu hovorim "deal"! :-)
Pepa
Pepa (neregistrovaný)
26. 10. 2005 9:14 Nový

Re: Chyby v mereni

celé vlákno
Ale Bóďo, podívej se na ceník Oracle, než budeš něco plácat.
Richard
Richard (neregistrovaný)
26. 10. 2005 11:40 Nový

Re: Chyby v mereni

celé vlákno
Robim na jednej aplikacii kde zakaznik (stat) plati Oraclu (DB, Cluster DB, AS) 3M SKK rocne za upgrade a za support (celkovo stali licencie cca 20M). V tomto pripade by bol MySQL lepsi.
rezna
rezna (neregistrovaný)
26. 10. 2005 12:09 Nový

Re: Chyby v mereni

celé vlákno
nemyslim si ;) - MySQL rozhodne neni stavene na velke projekty, uz prave treba absenci Stored Procedur, nebo chybejicimi views (ve starsich verzich) nebo parametrickych views (v 5.0).

jako proti oraclu je mysql 'sracka' kterou bych si na projekt nevzal - jestlize mate spravovat distribuovanej system DB ktere se replikuji z centralni DB pro celou republiku a DB ma klidne pres 30GB tak proste MySQL nema sanci ani kdyby se na hlavu stavela.
Martin Hudec
28. 10. 2005 18:39 Nový

Re: Chyby v mereni

celé vlákno
Chhhh.

Nevies rozlisit medzi rozsiahlostou a druhom projektu a tym, ci na to chces pouzit Oracle alebo MySQL. Niekto skratka nepotrebuje Oracle na fungovanie na projektoch, ktore su mensie nez tvoj distribuovany system replikovanych databaz pre celu republiku. Mozno tam MySQL nema sancu, mozno ale na niecom mensom vie byt MySQL so svojim features vhodnejsi kandidat nez Oracle. Tvoj pristup je stylom, kupim si dvojliter auto, jazdim s nim z prace a do prace, ved ta jednadvojka je o hovne, to nema 2 litre! Absolutne neefektivne pouzitie v danom pripade. Neber teda ze Oracle je vseliek najlepsi na vsetko, su nasadenia, kde proste je zbytocny. Lenze ty si a priori zaujaty. Skoda. Preto mozno pri svojich projektoch a Oracloch castokrat prehajdakas vagon penazi, lebo proste nie si schopny najst ine, efektivnejsie riesenie, lepsie aplikovatelne na danu situaciu.

Ak sa mylim, tak ma oprav prosim. A prepac, ze som sklzol troska do osobnejsej roviny a jemne mimo temu debaty :). Len ma unavuju bitky medzi Oracle vs MySQL, Linux vs Windows a podobne.
uživatel si přál zůstat v anonymitě
26. 10. 2005 12:09 Nový

Re: Chyby v mereni

celé vlákno
lol fetujes? ... keby si nenapisal tu zatvorku, mozno by som sa k tvojmu nazoru priklonil.

ale uvedom si, ze ak v takejto aplikacii presadis nieco ine, tak vsetko co padne, padne na tvoju hlavu.

v tomto pripade je otazka, ci ten oracle je nutny (resp, ci to nie je kanon na vrabce). ale tvrdit ze mysql sa na takejto urovni dokaze co i len pozriet na oracle, to uz hranici s fanatizmom.
truba
truba (neregistrovaný)
26. 10. 2005 0:37 Nový

Re: Chyby v mereni

celé vlákno
Jinymi slovy navrhujete provest test znovu a "trosku" jinak - zapojeni cca 5 lidi na 10 mesicu. :-)
marx
marx (neregistrovaný)
25. 10. 2005 1:23 Nový

Firebird radšej nie

celé vlákno
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 :) ).
Almad
Almad (neregistrovaný)
25. 10. 2005 2:07 Nový

Re: Firebird radšej nie

celé vlákno
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?
agent
agent (neregistrovaný)
25. 10. 2005 3:26 Nový

Re: Firebird radšej nie

celé vlákno
A to jako s každou novou verzí Firebirdu dáte 3000 jenom proto, abyste měl aktuální dokumentaci?
Pavel Císař aura:100
25. 10. 2005 10:17 Nový

Re: Firebird radšej nie

celé vlákno
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.
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 12:06 Nový

Re: Firebird radšej nie

celé vlákno
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.
Pavel Císař aura:100
25. 10. 2005 13:36 Nový

Re: Firebird radšej nie

celé vlákno
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.
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 14:29 Nový

Re: Firebird radšej nie

celé vlákno
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.
Pavel Císař aura:100
25. 10. 2005 19:01 Nový

Re: Firebird radšej nie

celé vlákno

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.

Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 21:48 Nový

Re: Firebird radšej nie

celé vlákno
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.
Pavel Císař aura:100
26. 10. 2005 10:37 Nový

Re: Firebird radšej nie

celé vlákno
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.
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
26. 10. 2005 15:06 Nový

Re: Firebird radšej nie

celé vlákno
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.
Pavel Janoušek aura:43
5. 12. 2005 14:16 Nový

Re: Firebird radšej nie

celé vlákno
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++.
MaReK Olšavský aura:100
26. 10. 2005 7:30 Nový

Re: Firebird radšej nie

celé vlákno

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í :-)

Pavel Císař aura:100
26. 10. 2005 10:12 Nový

Re: Firebird radšej nie

celé vlákno
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.
Pavel Janoušek aura:43
5. 12. 2005 14:21 Nový

Re: Firebird radšej nie

celé vlákno
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.

talpa
talpa (neregistrovaný)
4. 9. 2006 15:35 Nový

Re: Firebird radšej nie

celé vlákno
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.
marx
marx (neregistrovaný)
25. 10. 2005 12:44 Nový

Re: Firebird radšej nie

celé vlákno
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.
Pavel Císař aura:100
25. 10. 2005 13:41 Nový

Re: Firebird radšej nie

celé vlákno
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.
marx
marx (neregistrovaný)
25. 10. 2005 14:27 Nový

Re: Firebird radšej nie

celé vlákno
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.
uživatel si přál zůstat v anonymitě
25. 10. 2005 3:22 Nový

Re: Firebird radšej nie

celé vlákno
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.
pkm
pkm (neregistrovaný)
25. 10. 2005 7:06 Nový

Re: Firebird radšej nie

celé vlákno
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.
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 13:46 Nový

Re: Firebird radšej nie

celé vlákno
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.
Pavel Císař aura:100
25. 10. 2005 19:11 Nový

Re: Firebird radšej nie

celé vlákno
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.
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 22:00 Nový

Re: Firebird radšej nie

celé vlákno
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.
benzin
benzin (neregistrovaný)
26. 10. 2005 12:24 Nový

Re: Firebird radšej nie

celé vlákno
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.
benzin
benzin (neregistrovaný)
26. 10. 2005 12:26 Nový

Re: Firebird radšej nie

celé vlákno
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.
truba
truba (neregistrovaný)
26. 10. 2005 0:33 Nový

Re: Firebird radšej nie

celé vlákno
Myslite, ze MySQL je mene "tajemna" a vice proverena, kdyz ji kazdy php trouba pouzije pro webove stranky sve vesnice? ;-)
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
26. 10. 2005 15:32 Nový

Re: Firebird radšej nie

celé vlákno
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.
Ludvik Roubicek
Ludvik Roubicek (neregistrovaný)
25. 10. 2005 7:21 Nový

Re: Firebird radšej nie

celé vlákno
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.
misch
misch (neregistrovaný)
25. 10. 2005 8:52 Nový

Re: Firebird radšej nie

celé vlákno
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?

Ludvik Roubicek
Ludvik Roubicek (neregistrovaný)
25. 10. 2005 17:04 Nový

Re: Firebird radšej nie

celé vlákno
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...
Jan Sunavec
Jan Sunavec (neregistrovaný)
25. 10. 2005 10:06 Nový

Re: Firebird radšej nie

celé vlákno
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..
Ludvik Roubicek
Ludvik Roubicek (neregistrovaný)
25. 10. 2005 17:38 Nový

Re: Firebird radšej nie

celé vlákno
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.
Radim Bernatik
25. 10. 2005 7:33 Nový

Re: Firebird radšej nie

celé vlákno
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 ...
Leos Literak
Leos Literak (neregistrovaný)
25. 10. 2005 8:21 Nový

Re: Firebird a JDBC

celé vlákno
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.
Lukáš Zapletal
25. 10. 2005 20:45 Nový

Re: Firebird a JDBC

celé vlákno
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í.
jozef
jozef (neregistrovaný)
26. 10. 2005 9:33 Nový

Re: Firebird a JDBC

celé vlákno
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.
Marian
Marian (neregistrovaný)
27. 10. 2005 22:02 Nový

Re: Firebird a JDBC

celé vlákno
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.
Samuel Kupka aura:83
25. 10. 2005 4:45 Nový

Dakujem za clanok

Dakujem autorovi za clanok. Sice pouzite testy vazne neodpovedaju realnej prevadzke a aj platforma Windows pre mna nie je zaujimava, aspon mi autor nasadil do hlavy chrobaka ohladom databazy Firebird. Vzdy beriem tieto testy ako nerealne a preto vysledky z nich jednoznacne ignorujem, ale urcite su dobre aspon na to, aby ma prinutili pohnut svojim tucnym zadkom a skusit nieco nove. Takto som napriklad pred casom presiel na ReiserFS a tomu testu, ktory ma s nim oboznamil som neuveritelne vdacny.
uživatel si přál zůstat v anonymitě
25. 10. 2005 7:37 Nový

dotaz

celé vlákno
byl u postgresu po pridani indexu proveden vacuum analyze ?, jake bylo nastaveni postgresu zejmena parametru shared_buffers, work_mem a fsync(pokud vam jde jen o rychlost selectu). predpokladam ze ste pouzil defaultni nastaveni. opravdu "kvalitni" test rychlosti
Jan Sunavec
Jan Sunavec (neregistrovaný)
25. 10. 2005 10:10 Nový

Re: dotaz

celé vlákno
Vsetky nastavenia boli default. Po pridani indexu nebol prevedeny vacuum analyze. Aj ked 8.1 by mala mat autovacuum.
P.L.
P.L. (neregistrovaný)
25. 10. 2005 11:15 Nový

Re: dotaz

celé vlákno
Bez vacuum analyze postgres opravdu nefunguje dobre.

Pokud se nepletu, tak se autovacuum spousti napozadi v zavislosi na poctu zmen v tabulce ... ale s velkou pravdepodobnosti mu to nejakou dobu trva (pouzivam postgres 7.4, u 8.1 to ale bude podobne)

Docela by bylo zajimave videt vystup z explain analyze pro prislusny 'pomaly' dotaz. Pomerne snadno se pak da najit, v cem je chyba.
Dominik Sauer
Dominik Sauer (neregistrovaný)
25. 10. 2005 7:57 Nový

Hodnocení 2 - chyba:

Použít cluster index a pak se divit, že jede full scan namísto index scanu... mrkev v zimě...
pavel
pavel (neregistrovaný)
25. 10. 2005 8:17 Nový

Jaký nástroj pro managing Firebird

celé vlákno
Píšte, že byl problém nalézt nástroj pro managing Firebirdu. Co jste použil?
Jirka
Jirka (neregistrovaný)
25. 10. 2005 14:07 Nový

Re: Jaký nástroj pro managing Firebird

celé vlákno
Asi bych to upresnil...je problem najit dobry nastroj zadarmo.
Nastroju zadarmo je hodne, ale nejsou prilis zdarile, tech placenych uz je mene, zato jsou vytecne, napriklad:
http://www.ibmanager.com/
http://www.ibexpert.com/
Pavel Císař aura:100
25. 10. 2005 19:14 Nový

Re: Jaký nástroj pro managing Firebird

celé vlákno
Pokdu vám nevadí windows, tak skvělý nástroj zadarmo je IBExpert Personal. Má sice ořezané některé pokročilé funkce, ale na běžnou práci toho umí vic než dost.
Leszek
Leszek (neregistrovaný)
19. 11. 2005 0:59 Nový

Re: Jaký nástroj pro managing Firebird

celé vlákno
Vyskoušel jsem jich víc a IBExpert je nejlepší
Buthrakaur
Buthrakaur (neregistrovaný)
25. 10. 2005 22:55 Nový

Re: Jaký nástroj pro managing Firebird

celé vlákno
pro windows je docela zdarilej freeware nastroj IBQuery (http://www.mitec.cz/ibtools.htm)...
uživatel si přál zůstat v anonymitě
25. 10. 2005 8:22 Nový

a co ...

celé vlákno
... SQLite? co byste rekli o tomto heblu?
ND
ND (neregistrovaný)
25. 10. 2005 9:15 Nový

Re: a co ...

celé vlákno
Že je to C knihovna a ne databáze v tom smyslu, jako jsou ty testované. Nejlepší je na nenáročné použití tam, kde chcete něco velkého přenositelně uložit do jednoho souboru. Já s tím třeba provozuju účetní deník.
Ondrej Jombík
Ondrej Jombík (neregistrovaný)
26. 10. 2005 6:50 Nový

Re: a co ...

celé vlákno
SQLite je velmi sikovna a uzitocna databaza. Samozrejme hodi sa len na urcite veci. Priklad: predstavte si, ze mate nejaku aplikaciu, ktoru pravidelne distribuujete svojim klientom. Ta aplikacia nieco pocita, konieckoncov, to robi vacsina programov ;-)

Ked navrhnete dostatocne univerzalne API a priclenite SQLite databazu, mozete releasnut len jednu verziu kodu a klientom uz len dodavat databazove updaty -- nove tabulky, ciselniky, atd. Rovnako tak to funguje aj pre update pripadnych algoritmov. Akou technologiou budu algoritmy implementovane a vykonavane uz prenechavam na vlastnu kreativitu; PHP, Perl, Python, Pike, Ruby, Lua, ... skratka moznosti je velmi vela.
Michal Kára
Michal Kára (neregistrovaný)
25. 10. 2005 8:43 Nový

Metodika testovani

celé vlákno
Souhlasim s predreciky, ze zvolena metodika je dost nanic a vysledky maji zhruba stejnou vypovidaci hodnotu jako kdyby byly z vystupu nahodneho generatoru...

Udelat DOBRE porovnani neni vubec zadna legrace. Uplne nejjednodussi test bych si predstavoval tak, ze bych mel treba jednu tabulku (samozrejme zaindexovanou - pokud se musi casto delat scan tabulky, je to chyba aplikace). Generoval bych pseudonahodne N dotazu za sekundu, z cehoz treba 10% by byly insert, 70% update a 10% delete. Ty dotazy by bylo nutno pridelovat threadum testu, aby se pri zatizeni databaze nesnizil pocet dotazu za sekundu. Zacinalo by se z predem definovaneho stavu, udelalo by se treba 10 tisic dotazu (pro natazeni indexu do caches atp.) a pak by se teprv zacalo merit.

Pocet dotazu za sekundu by se postupne zvysoval a merila by se doba odezvy pri postupne se zvysujicim N.

Takze asi tak. Ale tohle rozhodne neni test na jedno odpoledne a stejne meri jen urcity rezim prace databaze - pro jine rezimy by jeho vypovidaci hodnota byla mala.
Jan Sunavec
Jan Sunavec (neregistrovaný)
25. 10. 2005 10:13 Nový

Re: Metodika testovani

celé vlákno
Siel som na to rovnako, ale potom ma napadlo ze je to cista utopia. Aj keby som spravil taky test, stale by to bola "umelina".
Honza (Jerry) Jaroš
25. 10. 2005 10:20 Nový

Re: Metodika testovani

celé vlákno
Nechci kverulovat, náčelníku, ale tohle umělina není?
Jan Sunavec
Jan Sunavec (neregistrovaný)
25. 10. 2005 10:22 Nový

Re: Metodika testovani

celé vlákno
Jasne ze aj toto je "umelina", netvarim sa ze nieje..
Michal Kára
Michal Kára (neregistrovaný)
25. 10. 2005 10:34 Nový

Re: Metodika testovani

celé vlákno
Nelze pochopitelne udelat test, ktery by dal vysledek "databaze A je obecne lepsi nez databaze B". Vzdycky udelate test, ktery ma nejake parametry - zpusob pousteni dotazu (konstantni pocet dotazu za sekundu, nebo konstantni pocet threadu), pomery, strukturu DB, velikosti tabulek atp. Pro takovyto konkretni test dostanete odpoved "databaze A je o tolik a tolik lepsi nez databaze B". Kdyz se pak budete v praxi rozhodovat, kterou databazi pouzit, tak musite mit test, ktery se vasi realne situaci co nejvice blizi.

Co chci rict je, ze test pouzity ve clanku neni moc realisticky ve smyslu ze zrejme existuje velmi malo praktickych aplikaci, kterym by byl podobny. To co jsem popsal ja uz je IMHO podobne mnohem vice aplikacim.
uživatel si přál zůstat v anonymitě
25. 10. 2005 8:44 Nový

MySQL InnoDB

celé vlákno
Pokud jde o MySQL, je třeba použít tabulky typu InnoDB. Ty kromě toho že mají vyšší výkon podporují na rozdíl od defaultního MyISAM i zmiňované cizí klíče (foreign key). No a nebylo by od věci proměřit i MySQL 5.0, když už je teď final (a v době testů bylo ve fázi posledních příprav na final, podobně jako PostgreSQL 8.1). Bez InnoDB tohle testování nevypovídá o plných schopnostech MySQL - to je asi jako kdybyste měřili maximální rychlost auta a nezařadili víc než dvojku...
Michal Molhanec aura:100
25. 10. 2005 11:44 Nový

Re: MySQL InnoDB

celé vlákno
no nevim, IMHO je MyISAM rychlejsi.
uživatel si přál zůstat v anonymitě
25. 10. 2005 12:32 Nový

Re: MySQL InnoDB

celé vlákno
MyISAM je rychlejší pouze v základních případech. Na komplikovanější dotazy, a obzvlášť na paralelní přístup k datům pro více klientů najednou, je podstatně rychlejší InnoDB.
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 14:44 Nový

Re: MySQL InnoDB

celé vlákno
Nikoli, InnoDB je mnohem rychlejší, a to už i na malých databázích a při používání základních věcí. Zjistil jsem, že klasickou metodou, jak brutálně zrychlit běžnou MySQL databázi je převést prostě tabulky z MyISAM do InnoDB.
Michal Molhanec aura:100
25. 10. 2005 14:59 Nový

Re: MySQL InnoDB

celé vlákno
nevim, me v mem minitestu vychazi INSERT u innodb o rad pomalejsi nez u myisam. asi delam neco blbe
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 18:12 Nový

Re: MySQL InnoDB

celé vlákno
Já se přiznám rovnou bez obalu, že jsem netestoval elementární akce typu rychlost INSERTu. Prostě jsem u několika databází různých velikostí a různě složité datové struktury pokusně zkusil switchnout tabulky z MyISAM na InnoDB. Výkonnostní nárůst mě opravdu překvapil. Co mě překvapilo ještě více byl fakt, že po přečtení několika stránek v manuálu MySQL ohledně InnoDb a vyladění konfiguračních parametrů MySQL plus některé drobné změny ve struktuře databáze znamenaly další výrazné urychlení práce s tabulkami InnoDb oproti MyISAM.

Přikládám to tomu, že InnoDB je mnohem lépe vymyšleno a pokud vím, tak InnoDB není dílem firmy, která programuje MySQL. Mám dokonce dojem, že společnost, která vyvíjela InnoDB koupil teď někdy Oracle a bude pokračovat ve vývoji on.
Michal Molhanec aura:100
25. 10. 2005 19:22 Nový

Re: MySQL InnoDB

celé vlákno
no je pravda, ze jsem pouzival autocommit, kdyz jsem si s tim chvili hral, tak jsem se dostal pod myisam docela rychle, takze asi mate pravdu (cimz vznika otazka smyslu existence myisam)

ano, innobase byla koupena Oraclem (viz tiskova zprava: http://www.oracle.com/corporate/press/2005_oct/inno.html ) -- predpokladam, ze mysql maji dostatecne kvalitni smlouvu, aby v pripade neochoty oraclu pokracovat mohli udelat vlastni fork
Richard
Richard (neregistrovaný)
26. 10. 2005 12:05 Nový

Re: MySQL InnoDB

celé vlákno
Obavam sa, ze nie. Oracle asi uz zacal citit konkurenciu MySQL v komercnej sfere a preto kupil InnoBase.
Vencour
Vencour (neregistrovaný)
16. 7. 2006 21:40 Nový

Re: MySQL InnoDB

celé vlákno
Já někde čet, že MySQL bude muset hodit s vlastním formátem, jelikož s InnoBase asi nebude moci v budoucnosti počítat. Tedy potvrzuji
Meesha
Meesha (neregistrovaný)
16. 5. 2006 8:05 Nový

Re: MySQL InnoDB

celé vlákno
MyISAM je rychlejsi v pripade, ze se z tabulky prevazne selectuje. InnoDB (krome toho ze podporuje FOREIGN KEY pro zavedeni relaci) je rychlejsi u tabulek, do kterych se prevazne insertuje a updatuje v nich (protoze nezamyka celou tabulku, ale jen aktualni radek). Prakticky jsem to vyzkousel u sebe a pokud jsou tabulky typu MyISAM, web lita rychleji a zatez serveru je pres cely dan stabilnich cca 10%. Zmenil jsem tabulky na InnoDB a web je znatelne pomalejsi a zatez serveru je 20%. Poznal jsem to hlavne v tabulce, kde je 1 200 000 zaznamu, co zaznam jedno bezne slovo do 10ti znaku. Nad touto tabulkou se provadi select name='slovo' a potom group by (polozka_id). Toto bylo z MyISAM tabulky hotove za 0.1 vteriny a tedka s InnoDB ten stejny dotaz, jen jiny typ tabulky trva 1.5vteriny. Jeste budu testovat Firebird, jak si s timto poradi.
Pichi aura:74
25. 10. 2005 12:00 Nový

Re: MySQL InnoDB

celé vlákno
No ale např. ve Veyronu by jsi na tu jedničku mohl jet přes 100 km/h a že je to hodně rychlé auto by jsi se asi nespletl.
Petr Bravenec
Petr Bravenec (neregistrovaný)
25. 10. 2005 9:17 Nový

Na rychlosti nezáleží

celé vlákno
Nechci nijak hodnotit článek - neznám ani MySQL ani Firebird.
V databázi PostgreSQL mám hrubě přes deset miliónů záznamů. Pro databázi mám vyhrazených 1.5 GB RAM. Největší tabulku (zhruba 9 mil. záznamů) procházím sekvenčně nějakých dvacet vteřin, občas (jednou za měsíc) potřebuju přepočítat nad tabulkou nějaké statistiky, pak mašinka chrastí s disky několik minut. V reálném provozu je ale práce s těmito daty řádově v milisekundách. Takto rozsáhlý objem dat mě nutí psát aplikace jinak - vytvářet pomocné tabuky a krmit je přes triggery. Databáze je složitější o pomocné tabulky a pár funkcí a triggerů, aplikace je napsaná trochu nelogicky (data sypu to jedné tabulky, ale statistiky tahám odjinud), ale v reálném provozu díky tomu položím na lopatky kteroukoli nejrychlejší databázi bez těchto možností. Rychlost databáze pro mne NENÍ podstatná, v objemu miliónů záznamů bude každý databázový stroj pomalý. Podstatnější je, jestli databáze má dostatek prostředků pro vytváření "zkratek" a jestli dovede udržet tyto "zkratky" v konzistentním stavu.
Pedro
Pedro (neregistrovaný)
25. 10. 2005 10:20 Nový

Re: Na rychlosti nezáleží

celé vlákno
K tomuto nazoru sa ciastocne pridavam. ciastocne preto, lebo pri velkych objemoch dat (nielen poctom zazanmov, ale aj velkostou dat) a netrivialnych manipulaciach s datami je vyladeny postgres asi stale najrychlejsi. Tento clanok by bol fajn, keby autor na zaciatku uviedol, ze testuje vhodnost pouzitia DB na webovy chat s jednou - dvoma tabulkami.
Boss
Boss (neregistrovaný)
25. 10. 2005 12:48 Nový

Re: Na rychlosti nezáleží

celé vlákno
Ja mam v postgresql 8 asi 5GB dat a nemuzu si ji vynachvalit. Ja bych jeste podotknul, ze neni od veci obcas nechat zanalyzovat vsechny tabulky. Planer ma pak statisticke informace o jejich velikosti a dokaze tak lepe optimalizovat dotaz. Musim portvrdit, ze pri vyberu DB u me hrali roli predevsim vlastnosti DB.
uživatel si přál zůstat v anonymitě
25. 10. 2005 9:37 Nový

blbe testy, skuste daco realne :-))

napr.
- select konkretneho usera podla l/p z povedzme 100k, 500k, 1M riadkov
- statisticke vypocty (count + where + group by) nad 1M, 10M, 100M riadkov
- nejake transakcne veci (kde sa uplatni jednotlivy model lockovanie - test ma nenapada)
podlesh
podlesh (neregistrovaný)
25. 10. 2005 9:46 Nový

zatížení?

Kromě jiných nedostatků tam chybí sledování vytížení procesoru. Konkrétně to byl náš důvod proč jsme museli přejít z Postgresql na MySQL - rychlostně bylo všechno v pořádku, dokud měl vlastní stroj. Jenomže když to mělo být všechno na jednom stroji (reálné nasazení), tak se ukázalo že žere 30-50% výkonu a to v tomto případě dost vadilo (aplikace ho sama dost potřebovala). Jenomže už je to pár let, tak nevím zda se to změnilo k lepšímu...
Karel Zak aura:100
25. 10. 2005 9:58 Nový

Super

celé vlákno
Super test. Uz jsem se dlouho takto nepobavil :-)))
uživatel si přál zůstat v anonymitě
25. 10. 2005 10:38 Nový

Re: Super

celé vlákno
Pripajam sa k ovaciam. Tiez som sa dlho nepobavil. Tento test by som skor hodnotil ako test s nazvom "Ake databazove servre pozname zadarmo" .. ale urcite nie na porovnavanie vykonu. Taketo t.z. benchmarky su velmi zavadzajuce a nepresne a dovolim si povedat, dost od veci. Ale snaha sa vzdy ceni :).. Ale tu snahu by som skor smeroval niekde tam, kde to bude mat aspon opodstatnenie.
leonell
leonell (neregistrovaný)
25. 10. 2005 12:58 Nový

Re: Super

celé vlákno
Az na to ze MySQL narozdil od Firebird ci Postgresql neni pro spoustu pouziti zadarmo ....
Lukáš Zapletal
25. 10. 2005 20:50 Nový

Re: Super

celé vlákno
A na to bych také poukázal - hodně lidí spojuje MySQL s weby, kde je zdarma. Po přečtení licence někomu ale může spadnout hřebínek, a zjisťuje, že se jedná vlastně o licenční "virus".
Pichi aura:74
26. 10. 2005 9:59 Nový

Re: Super

celé vlákno
MySQL je licencováno duálně, přičemž jedna z licencí je GPL. Pokud MySQL používám pod GPL a v souladu s ní, už mě nic jiného nemusí zajímat a také nezajímá. Druhá licence mě zajímá pouze pokud MySQL chci používat v rozporu s GPL. Pokud kdokoli tvrdí cokoliv jiného, je to jeho věc a mě to nemusí zajímat a také nezajímá. A to včetně MySQL AB, ti dokonce mohou v rámci svých vlastních obchodních záměrů mohou klidně i lhát a já jim to nehodlám zazlívat. Vaši motivaci však nechápu. Takže si to ještě jednou nechte pěkně projít hlavou a pak sem piště podobné bláboly.
Lukáš Zapletal
26. 10. 2005 12:07 Nový

Re: Super

celé vlákno
Na podobné "výlevy" obvykle neodpovídám, ale mystifikujete tady, a to se mi nelíbí. Duální licencování není nic špatného, nic v rozporu s GNU GPL.

MySQL prostě nemůžete použít v closed-source projektech, které nejsou webové (resp. které nejsou v souladu s tím, co píše MySQL AB). Nemůžete s ní dělat byznys, to je vše. Lidi to často ani neví.
Lukáš Zapletal
26. 10. 2005 12:09 Nový

Re: Super

celé vlákno
Teď mystifikuju já, takže to upřesním... Můžete, ale musíte zaplatit. Na obranu MySQL AB - ceny nejsou vysoké, ve firmě, kde jsem kdysi působil, se kupovala licence několikrát.
Lukáš Zapletal
26. 10. 2005 12:27 Nový

Re: Super

celé vlákno
A nebo dělat byznys s GNU GPL, což je pro malé firmy dost těžké. Jisté výjimky jsou pro PHP. A vůbec, už Vám to tady nebudu vysvětlovat, předpokládám, že to ani nebude mít smysl, kdokoliv si může najít MySQL licenci.

ps - srovnejte - PostgreSQL: BSD licence, Firebird: varianta MPL
Pichi aura:74
26. 10. 2005 13:10 Nový

Re: Super

celé vlákno
No bezva, děkuji, že jste dal za pravdu mému "výlevu". Ono vám taky nic jiného nezbylo jelikož byl pravdivý narozdíl od vašeho "výlevu" na adresu MySQL.
Lukáš Zapletal
26. 10. 2005 13:21 Nový

Re: Super

celé vlákno
Hynku já se opravdu nemíním nějak dohadovat. Kdokoliv si tu licenci může přečíst a udělat si obrázek. Napsal jsem, že si je dobré na to dát pozor a pokud někdo nechce/nemůže "virovou" GNU GPL, pak musí zaplatit. Nechápu, co Vás podráždilo...
Pichi aura:74
26. 10. 2005 14:45 Nový

Re: Super

celé vlákno
No teď jsem si ty příspěvky znovu pozorně přečetl a musím se omluvit. Ty formulace ve tvém i předchozím příspěvku jsou sice citově zabarvené, ale pravdivé. MySQL opravdu nelze použít všude zadarmo narozdíl od BSD licence PosgreSQL. Nicméně ji lze použít zadarmo i v komerčních projektech a nejen "na webu". Jestli někomu vadí "virovost" GNU GPL, tak opravdu produkt pod GNU GPL není pro něj, ale musí se poohlédnout po jiné licenci a i to mu MySQL umožní akorát už to není zadarmo.
Lukáš Zapletal
26. 10. 2005 14:51 Nový

Re: Super

celé vlákno
A vše se vyřešilo. Já si uvědomuji vážnost a důležitost GNU GPL, ale nechápu přístup firmy, která ji tak trochu "zneužívá". Sama chce vydělávat, ale ostatním to svým způsobem ztěžuje. Asi jsem měl slova volit tak, aby to neznělo tak v "neprospěch" GNU GPL. Licence jako taková pochopitelně není virus, jen je orientovaná spíše na obranu komunitního způsobu vývoje. MySQL to převrací, ale DB je to fajnová. Kdyby byl tehdy Firebird, asi bych svůj systém vytvořil na něm...
Pichi aura:74
26. 10. 2005 15:03 Nový

Re: Super

celé vlákno
Neřekl bych zneužívá. Vůbec ničeho nezneužívá. Prostě MySQL AB něco vytvořila a může si s tím dělat co chce. To že to ještě ke všemu dá k dispozici pod GPL je její obrovské plus. To, že to pokytuje i těm, kteří nemohou (spíš neumějí) vyhovět GPL, je její byznys. V tom není žádné zneužívání. Naopak já v příspěvku uvádím příklad jak se toho dá snadno zneužít. Stačí si vzít zdrojáky mysql řádkového klienta a popsaným postupem můžete GPL snadno zneužít a nikdo vám v tom nemůže zabránit. Stačí ještě vyhovět některým nuancím 2. hlavy GNU GPL týkající se distribuce a zneužijete GPL levou zadní.
benzin
benzin (neregistrovaný)
26. 10. 2005 17:18 Nový

Re: Super

celé vlákno
Ani jedno neni zneuziti Licence. Vsichni kdo delaji pod GNU GPL vi jak se jejich produkt da vyuzit, presto ho poskytnou. Proc tedy tvrdit ze jde o zneuziti, to je pouze Vase spatne svedomi, ale vubec neni duvod aby bylo cerne.
Lukáš Zapletal
26. 10. 2005 18:13 Nový

Re: Super

celé vlákno
Všimněte si, že slovo "zneužít" mám v uvozovkách (myslím, blbý je, že root nezobrazí celý thread při odpovědi). Tím jsem chtěl spíš říci, že GNU GPL spíše špatně využívají. "Zneužívají" ji k tomu, aby tlačili na firmy - "Kupte si licenci". K tomu nebyla GNU GPL stvořena.
Pichi aura:74
26. 10. 2005 14:54 Nový

Re: Super

celé vlákno
Mimochodem vyloženě lživý je například výrok: "Nemůžete s ní dělat byznys, to je vše." viz. Tento váš příspěvek. Dokážu si třeba představit model vytvoření GPL metaserveru nad GPL knihovnami MySQL a potom k němu napsat úplně closed source klienta. Prostě oddělit GPL část od svého produkty a s drobnou ztrátou výkonu (která při vhodně navrženém rozhraní, třeba unixovou pipe nemusí být vůbec bolestivý) a mám komerci jak bič a MySQL AB se může se jít klouzat a nedostane ani korunu. Budou to oddělené procesy a ani RMS nemůže říct ani popel.
Lukáš Zapletal
26. 10. 2005 15:12 Nový

Re: Super

celé vlákno
Já jsem tušil, že to mám víc zpřesnit :-)

Podle licence _nemůžete_ zdarma používat MySQL, pokud je těsně svázaná s aplikací. Musí být zajištěno, že aplikace bude fungovat i na jiných DB strojích. Takhle to bylo v dobách verze 3.X, kdy jsem si licenci pečlivě nastudoval a nepředpokládám, že by tomu bylo jinak. Nepomůže tomu ani tisíc vložených vrstev - mají to ošetřeno.

Stavět moji údajnou "lež" na jakémsi pochybném "hacku" se mi nezdá příliš vhodné. A vůbec, nechme už toho...
kocour_easy
kocour_easy (neregistrovaný)
25. 10. 2005 11:44 Nový

MySQL

celé vlákno
MySQL mi pri startu alokuje 12 procesu a kazdy po 20M.A to mam tabulku z 10 sloupci a 35 zaznamu.A to jse pouzil my-small.cnf.Teda Vam reknu, ze pekny zrout.
Michal Molhanec aura:100
25. 10. 2005 11:58 Nový

Re: MySQL

celé vlákno
tak to tam mas nekde chybu
Tom
Tom (neregistrovaný)
25. 10. 2005 13:02 Nový

Re: MySQL

celé vlákno
No .. chyba s vloudila.. to neni 12*20 .. ale tech 20mega poziraji ty procesy dohromady...
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 13:58 Nový

Re: MySQL

celé vlákno
Tady by stačilo zhruba dvacet minut věnovat přečtení manuálu MySQL a snadno a rychle tam najdete jak tyto věci nastavit. Právě nastavení velikosti paměti několika bufferů, které si MySQL drží, a jejichž velikost můžete v e velkém rozmezí škálovat je docela dobrá věc. MySQL tak nějak předpokládá, že si těch prá parametrů nastavíte podle toho, co potřebujete. Pokud použijete prefabrikované řešení typu my-small.cnf, tak se nesmíte divit.

Právě možnost tyto informace rychle najít a použít, kterou mám u MySQL mi hrozně chybí u Firebirdu, kde v podstatě nemám možnost podobné údaje vůbec najít.
Lukáš Zapletal
25. 10. 2005 20:58 Nový

Re: MySQL

celé vlákno
Musím zde napsat, že i po optimalizaci mi MySQL (InnoDB) brala víc prostředků, než bylo zdrávo. Firebird vše zvládal s třetinovými nároky stejně rychle.
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
25. 10. 2005 22:26 Nový

Re: MySQL

celé vlákno
Jestli chcete optimalizovat MySQL na šetrnost k prostředkům počítače, nepoužívejte InnoDB. InnoDB je trochu kanón na vrabce a je dělaná na výkon a rozhodně prostředky počítače nešetří. Pokud vám záleží na každém bajtu, který databáze zabere, postavte to na MyISAM a pohrajte si s hodnotami bufferů.

Mám takhle na stařičkém notebooku (Pentium 166 MHz, 32 MB paměti, Windows 95) databázi nemovitostí v MySQL s několika stovkami tisíc záznamů a asi třiceti tabulkami a databázový server MySQL zabírá v paměti asi 1,5 MB. Práce s databází je velice rychlá.

Je třeba si také uvědomit určení databáze. Pokud potřebujete kvalitní databázi se všemi vymožnostmi relačních databází, myslím si, že MySQL není dobrá volba. Pro mě je MySQL takové inteligentnější pokračování DBF databází.
Lukáš Zapletal
25. 10. 2005 23:33 Nový

Re: MySQL

celé vlákno
Tady jste mě asi nepochopil. To, že potřebuji minimalizovat nároky na pamět nutně neznamená, že se nejedná o mission-critical aplikaci. Je to klíčový informační systém firmy, který nelze na MySQL provozovat na jiných tabulkách, než typu InnoDB.

MySQL určitě nebyla dobrá volba, ale jak se aplikace rozrůstala, tak se stalo prakticky nemožné migrovat jinam. Používám příliš proprietárních věcí a když bylo potřeba použít vlastnosti dostupné na InnoDB, tak se to prostě přeplo. Proč taky ne, když to MySQL nabízí. Jinak jsem s provozem spokojen, po dobu 2 let žádný výpadek, zálohy probíhají korektně od prvotního nastavení. Jen té paměti si to žere...
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
26. 10. 2005 1:06 Nový

Re: MySQL

celé vlákno
Aha, rozumím. To je potom těžké, protože InnoDb je opravdu žravé. I když i to se dá částečně vyladit. Chce to pohrát si s konfiguračními volbami pro InnoDb, je jich slušná řádka. Ale samotná MySQL počítá s tím, že pro ní bude vyhrazeno asi 80% paměti stroje, na to byla navrhovaná. Dá se samozřejmě vyladit na daleko menší spotřebu, ale chce to si chvíli hrát s konfigurací.
Lukáš Zapletal
26. 10. 2005 11:46 Nový

Re: MySQL

celé vlákno
Ano, opravdu je to žrout. Možná je to tím, že je to v MySQL jakoby "navíc" - DB nebyla takto navržená. Nevím, vyladit by se to zcela jistě dalo, ale při zběžném přečtení manuálu jsem na to nepřišel.
Miloslav Ponkrác
Miloslav Ponkrác (neregistrovaný)
26. 10. 2005 14:51 Nový

Re: MySQL

celé vlákno
To máte naprostou pravdu. Taky mi někdy připadá, že InnoDb je v MySQL v podstatě cizí element.

S laděním MySQL jsem si už v životě docela dost užil. Asi největší zkušeností pro mě bylo, když jsem administroval MySQL pro dnes už neexistující DC hub - CZ PRO. Nad MySQL běželo několik náročných klientů a jedním z bych byl verlihub, ke kterému bylo běžně připojeno kolem 6000 uživatelů. Jak verlihub, tak i MySQL byli paměťoužrouti a bylo potřeba u MySQL nechat vysoký výkon za rozumné spotřeby paměti. Co mě ale velice překvapilo, že mě bohatě stačily k ladění informace z manuálu k MySQL.

Tedy k vašemu problému. Jak se ladí MySQL? Nejdříve si musíte uvědomit, jaké SQL oprerace se na něm skutečně provádějí, a které z nich jsou kritické. To asi nejvíce víte vy sám, co vám tam běhá.

1) Nejdříve je dobré nastavit obecné velikosti bufferů v konfiguraci MySQL serveru, které nezávisí na typu tabulek. Informace o tom v manuálu jsou, ale jsou bohužel rozházeny na různých místech. Klíčové je vhodně nastavit parametry key_buffer_size, join_buffer_size a sort_buffer_size. Jejich význam si snadno najdete v manuálu pomocí fulltextového vyhledávání.

2) Potom je vhodné nastavit parametry, které se týkají pouze InnoDb tabulek. Těch je trochu více a je potřeba jejich význam pochopit trochu do hloubky. Zde je ale manuál dobře popisuje, jejich přehled se základním popisem dostanete třeba zde (doporučuji ovšem návdavkem přečíst celou část o InnoDB):

http://dev.mysql.com/doc/refman/5.0/en/innodb-start.html

Pokud uděláte první pokus, nejspíše se dostanete na dost vysokou hodnotu ve spotřebě paměti, ale je potřeba body 1) a 2) párkrát opakovat, než to iterací dojde do vyladěného stavu.

Také velmi doporučuji přečíst si část pojednávající o optimalizaci MySQL obecně:

http://dev.mysql.com/doc/refman/5.0/en/optimization.html
Milan
Milan (neregistrovaný)
25. 10. 2005 12:07 Nový

Zcela spatne testovani

celé vlákno
Toto testovani ma jednu obrovskou chybu, ktera zcela znehodnocuje vysledky - nestaci pro kazdou databazi poslat xxx_query().

Nerikam, ze vidim uplne do hloubky, ale tento prikaz posle SQL dotaz do DB, DB prikaz rozparsuje, zanalyzuje, zoptimalizuje a pripravi vse mozne, ale vysledna data nevrati! A to se v praxi prece nedeje, vzdy je treba projit ve smycce (ktrera s daty klidne nic neudela, ale projde je) vsechna vracena data.

Muze autor clanku provest retest s tim, ze ve smycce projde ziskana data?
Michal Molhanec aura:100
25. 10. 2005 12:30 Nový

Re: Zcela spatne testovani

celé vlákno
no minimalne u MySQL je vrati; to byste musel pouzit mysql_unbuffered_query.
Michal Molhanec aura:100
25. 10. 2005 12:35 Nový

Re: Zcela spatne testovani

celé vlákno
u Firebirdu se pise: If you use ibase_query() for SELECT without fetching result then you must know that SELECT isn't actually executed. E.g. you perform "SELECT MY_UDF(param) from RDB$DATABASE" - MY_UDF isn't actually called until you fetch result.
uz chapu, proc byl tak rychly :-))))
uživatel si přál zůstat v anonymitě
25. 10. 2005 12:30 Nový

Re: Zcela spatne testovani

celé vlákno
Zrovna pro MySQL je použité měření v pořádku - autor použil mysql_query(), to donutí PHP aby všechna data načetlo z MySQL serveru do svého bufferu (můžou s tím být problémy, pokud PHP nemá k dispozici dostatek paměti). Podvod by byl kdyby se použilo mysql_unbuffered_query() a pak by se data nezpracovala. Jak je to pro jiné databáze to nevím, ale možná to bude podobné. Nebo že by to měl Firebird vyoptimalizované a proto byl tak podezřele rychlý?
Milan
Milan (neregistrovaný)
25. 10. 2005 14:09 Nový

Re: Zcela spatne testovani

celé vlákno
Viz. prispevek p. Molhance - prave u Firebirdu se to jen pripavi pro data, zadna data do PHP neproudi.

Mne se ty vysledky Firebirdu taky nejak nezdaly. Jak rikam, je treba to retestovat a clanek opravit ci vydat novy.
uživatel si přál zůstat v anonymitě
25. 10. 2005 21:40 Nový

Re: Zcela spatne testovani

celé vlákno
A nasledne po oprave, ktoru uvadzate, co tak pre zaujimavost ten kod
optimalizovat pre kazdu DB zvlast, napr. aj za pomoci prispievatelov do
diskusie, a vyskusat to potom, a pripadne zvatsovat objemy dat s ktorymi
sa pracuje.
Michal Kubeček
Michal Kubeček (neregistrovaný)
26. 10. 2005 2:05 Nový

Re: Zcela spatne testovani

celé vlákno
Asi jste přehlédl podstatný detail: do PHP nemá celkem co proudit, ten dotaz totiž vrací jen jeden řádek. Takže to, jestli ten jeden řádek načtete do PHP nebo ne, nehraje nějak zásadní roli, vše podstatné se děje už při volání ibase_query() (nebo, chcete-li, ibase_dsql_execute()) a ten jeden fetch nemá šanci výsledky podstatným způsobem ovlivnit. Stejně tak je v tomto případě celkem jedno, zda takový typ testu provádíte přes PHP API, céčkové API nebo třeba isql.
Pichi aura:74
26. 10. 2005 10:04 Nový

Re: Zcela spatne testovani

celé vlákno
No to právě nemusí být pravda pokud se to podstatné stane teprve při tom prvním a jediném fetch. A ty výsledku v článku spíš vědčí, že tu něco nehraje. Takže ten fetch udělejte a budeme se bavit dál, jo?
Michal Kubeček
Michal Kubeček (neregistrovaný)
26. 10. 2005 13:09 Nový

Re: Zcela spatne testovani

celé vlákno

Dobře, tak jsem to zkusil. Výsledek: 528 ms ibase_query(), 63 ms ibase_fetch_object() i ibase_fetch_row(). Aby byly výsledky méně zkresleny náhodnými fluktuacemi, zkusil jsem ještě totéž pro 1000000 náhodně vygenerovaných záznamů místo 266266. Dostal jsem 2058 ms versus 89 ms, tentýž dotaz v isql ukáže 2.23 s. Takže není pravda ani to, že by byl výsledek ovlivněn efektivitou PHP API, ani to, že by byl (zásadně) ovlivněn chybějícím fetchem.

Pravdu byste měli pouze u druhého testu (s indexem), pak to pro milion záznamů vychází 1 ms na ibase_query() a 730 ms na ibase_fetch_object()

Na druhou stranu se mi moc nezdá to, co píše autor o importu dat do tabulky. Mám podezření, že z neznalosti používal na každý řádek ibase_query(); při použití ibase_prepare() a ibase_execute() jsem měl tabulku naplněnou za 25 sekund, což by podle výsledků prvního testu odpovídalo necelým třem minutám na jeho systému.

Martin Povolny
25. 10. 2005 13:13 Nový

hroznej clanej, 0 bodu z 10

celé vlákno
Prectete si treba tohle, nez budete delat nejaky 'benchmark':

http://www.zedshaw.com/blog/programming/programmer_stats.html

Precetl jsem si na abclinuxu tradicne hodnotny clanek: preklad kernel traffic a pak jsem zacal cist na rootu tehle benchmark a akorat me to otravilo, spolecne s tim poslednim 'komixem', proste root.cz je v kytkach, zasla slava, je to vycpele :-(

Nekdy mene je holt vice.
rezna
rezna (neregistrovaný)
25. 10. 2005 15:42 Nový

Re: hroznej clanej, 0 bodu z 10

celé vlákno
rekl bych ze tech clanku co by tu nemely co delat je tu vic :) - vzpomenme treba na genialni clanek o skype - taky jenom blbe tlachani do vetru a haneni closed source aniz by autor vedel o cem pise.

a btw proc na serveru kde se sklonuje linux ve vsech padech delate testy na MS Widlous? - Kdyby to ten clovek aspon testoval na serverove instalaci na 2 procesorove stanici a ne na domacim celeronu kde to ma hoouby vysledky. Navic ani tak neni MS Widlous platformou kde by se tyhle DB pouzivali. POkud nasazuju server jako windows tak jedine s MSSQL nebo Oraclem (zalezi kolik zakaznik zaplati).
honzucha
honzucha (neregistrovaný)
25. 10. 2005 14:28 Nový

Srovnáni podle schopnosti

No kdyz uz teda srovnavate, tak by bylo dobry srovnavat nejen podle rychlosti, ale i podle vlastnosti, napriklad mysql ma pochybnou implementaci trigeru, vubez zadnou proceduralnich jazyků (takze to ze mysql nekde neco nejakym zpusobem vuselektilo rychleji, pro me nema smyslu, protoze me pripravuje o robustnost aplikaci, napr. prevest pl/sql fkce z oracle db je ve vetsine pripadu o minoritnich zmenach a pod). Jako docela dobry zdroj informaci doporucuji http://monstera.man.poznan.pl/jra1-wiki/index.php/Mysql_vs_postgres
MatBa.FDF
MatBa.FDF (neregistrovaný)
25. 10. 2005 14:46 Nový

Intel Celeron 2.2 MHz

celé vlákno
Mne teda uz na zacatku zarazilo ta kofigurace:

Ako počítač bol použitý:
Intel Celeron 2.2 MHz
768 MB RAM
20 GB Disk
MS Windows

Ja se priznam, ze nevim jestli intel vyrabel celerony uz v nekdy v roce 1990.

Ale jinak je to urcite zajimavy clanek pro ty, ktery chteji zacit vyvyjet aplikace provazane na databaze.
honza
honza (neregistrovaný)
25. 10. 2005 15:58 Nový

Re: Intel Celeron 2.2 MHz

celé vlákno
to je pouze redakcni chyba, ale ja jsem slysel, ze pani Dolezalova je v jinem stavu a pro nastavajici matku jsou ta technicka data prkotiny - ona ma v hlave dnes jine starosti...
Johanka Doležalová aura:100
26. 10. 2005 10:47 Nový

Re: Intel Celeron 2.2 MHz

celé vlákno
Proboha kdo takovou blbost siri?

Kdybys byl moje endokrinolozka, tak bys vedel, ze prijit do jinyho stavu mam zatim zakazany, navic jeste nejsem ani pani...:)
Jakub Hegenbart aura:84
1. 11. 2005 5:16 Nový

Re: Intel Celeron 2.2 MHz

celé vlákno
Samozřejmě, každý přece ví, že Johanka je chlap. ;-)

Ale nepochybně se už všichni těšíme na nového uživatele... :-))) ;-)
next
next (neregistrovaný)
25. 10. 2005 17:20 Nový

grafy?

celé vlákno
Tie grafy by si zasluzili 5 min prace, nasledne by boli 3x citatelnejsie.

a) nadpis - z "Meranie 1." sa nedozviem vobec nic -> neviem o com je graf
b) X a Y osi nemaju popisku -> zas neviem, o com ten graf je, ake informacie zobrazuje
c) bez popisiek osi nie je jasne, ci je "lepsia" mensia alebo vacsia hodnota na Y osi.

Keby som taky graf odovzdal v skole, vyhodili by ma zavretymi dverami. A mali by pravdu.
rezna
rezna (neregistrovaný)
25. 10. 2005 20:59 Nový

Re: grafy?

celé vlákno
kdysi jsme v notne podnapilem stavu odhodlali ke stvoreni apriloveho zertu - http://www.ceskehry.cz/magazin/view.php?cisloclanku=2004040101 .

tato recenze mi ho velice pripomina ;)
Dusan
Dusan (neregistrovaný)
25. 10. 2005 17:41 Nový

Zaujimave ...

Nechcem len kritizovat, ale tu sa da ocenit iba snaha. A najma vytvorenie dalsieho zbytocneho flamewar-u.
Ale miesto zabitia casu takymto "porovnanim" by bolo lepsie nastudovat tych X existujucich benchmarkov, co su na nete uz davno.
Ak je to s tym FB (nespustenie SELECT) naozaj tak, potom je to dost zabavne :-) Ze to autorovi vobec nenapadlo ... v kazdom teste 10-50 nasobne rychejsia DB ako je mysql, ci postgres ....
*** ROFL ***
Nerozumiem ani, preco na tom serveri vlastne bezal apache.
Lepsie by bolo pouzit http://vegan.net/tony/supersmack/ a definovat tam vlastne query .

Cisty amaterizmus.
uživatel si přál zůstat v anonymitě
25. 10. 2005 17:51 Nový

Nic

celé vlákno
Chtel jsem pridat k clanku reakci, ale po shlidnuti toho, kolik je toho tady napsano, jsem se prece jen rozhodl, ale nebudu kritizovat tolik.

- Testovat databazi v domacich podminkach je smesny.
- U grafu je jen nadpis "test c. 1" a podobne. No co to je? Hodnoty jsou tam ale kde jsou jednotky? To kvuli debilne udelanymu grafu musim cist cely balast hovadin, jen abych nekde uprostred vety nasel hlasku, ze na ose jsou sekundy, to nejde do toho grafu napsat tuto: [s]

Tim pro me cteni clanku skoncilo, pac nesplnuje zakladni sdelovaci podminky. To ze se autor zabyval tematem testovani rychlosti, neznamena to, ze tematu rozumi. Jen dospel k zaveru ze ...
uživatel si přál zůstat v anonymitě
26. 10. 2005 9:36 Nový

Re: Nic

celé vlákno
to testovanie nie je smiesne, smiesne su len navrhy testov.
vsetky testy sa robia za predpokladu, ked sila hardware prevysuje zataz testu.

v testoch zameranych na pretazenie systemu mal zas navrch postgresql ... dokonca trojnasobne oproti mysql.

v malych tabulkach mysql vedie, ale v komplexnosti a stabilite body straca.

nevraviac o sfetovanom manikovi, co im navrhuje syntax sql, asi by ho mohol niekto upozornit, ze existuje aj dajaky ten standart.
uživatel si přál zůstat v anonymitě
26. 10. 2005 21:11 Nový

Re: Nic

celé vlákno
Je vidět, že jste jako většina co MySQL pomlouva zastydnul u verze 3.24. Verzi 5 lze přpenout do ANSI kompatibilního módu.
MaReK Olšavský aura:100
26. 10. 2005 7:40 Nový

Test?

celé vlákno
    Reálný test si představuji trochu jinak a napsat testovací sadu je trochu složitější:
  • Rozhodně pro tento účel není vhodný scriptovací jazyk, ale jednoznačně například C++
  • Máte jistotu, že jste buď vždy převzal (fetch) data z SQL databáze, nebo že jste ji nechal přikaz udělat jen na prázdno?
  • Jaký typ indexu jste v PgSQL zvolil? A byl vhdný?
  • Operace na jedné tabulce a jen prosté SELECTY? Proč ne JOINy mezi tabulkami, výběry pomocí regulárních výrazů, subselecty, vkládání mazání a update ve vhodném poměru?
  • Takto to opravdu vypadá, že jste chtěl honorář a předvést, že nějaké databáze znáte.

IMO na konkurenčním serveru píšeme s kamarádem seriály o MySQL a PostgreSQL, do srovnání rychlosti se nehrneme a víme, proč to děláme ono stačí navrhnout testovací strukturu a indexy tak, že MySQL propadne o 500% i když tam bude jen 100 řádek.

uživatel si přál zůstat v anonymitě
26. 10. 2005 10:15 Nový

Re: Test?

celé vlákno
hej? a aky je dovod pouzit prave C++?
dolezite je predsa, aby pre kazdy jazyk bola pouzita "ta spravna metoda".
ak to niekomu vadi ...

imho je jedno v akom jazyku sa vykona. kludne aj sposobom "time $console -f $file"

ak, tak testovat C/C++, Java, Perl, PHP, Python, mozno sa najde aj dakto, kto spominane testy napise v Ruby. ale samozrejme, vzdy aj cez konzolu daneho stroja.

dolezity je navrh testu. vypracuj(me/te) pre vopred zadany hw a sw

- konfiguraciu sluzby (spolu so startup skriptami
- navrh struktury tabuliek
- inicializacne data, postup inicializacie
- testy

pred kazdym testom reboot, spustenie len testovanej databazy.
testy:
a) priame vykonavanie SQL
- synteticke selekty
- cykly select - insert - update
- triggre, view, ...

b) s vyuzivanim roznych optimalizacii prace (prepare statementy, vypnuty autocommit, ...)

synteticky test je jednouzivatelsky
realny test je test pri pripojeni viacerych klientov (navrhujem testovat 8, 16, 32, 64, 128, samozrejme s moznou roznou optimalizaciou na predpokladanu zataz)


a spravit rovno "velky test" na
postgresql 7.4, 8.0, 8.1
mysql 4.0, 4.1, 5.0 (ak existuju dolezite dalsie verzie, doplnte)
firebird
(a vsetky mozne i nemozne dostupne db, ako oracle, db2, sybase)


priklanal by som sa k testu pod linuxom, s odporucanou konfiguraciou kernelu (2.4 / 2.6 by tiez stalo za uvahu do testu zahrnut).


samozrejme, vsetky nastavenia/utility/generatory atd pod GPL (alebo aspon LGPL).


do banku davam
- stroj pre domace pouzitie (p4 2,4; 512 ram; 200GB sata)
- svoje znalosti perlu a postgresql
MaReK Olšavský aura:100
26. 10. 2005 11:08 Nový

Re: Test?

celé vlákno
Mno s pozadavkem na C++ jsem to mozna prepiskl, ale zase na druhou stranu je IMO lepsi kompilovany jazyk, nez scriptovaci (scriptovaci muze jet jako opravdu interpretovany, pripadne muze byt pri prvnim pruchodu interpretovany, ale dalsi prubehy cyklu mohou byt v jiz zkompilovane z cache..., anebo pred prvnim startem scriptu je docasne prelozen do strojoveho kodu a pak spusten, ...)
Ale zcela vazne, takto, jak bylo v tomto clanku test nema zadnou vypovidaci hodnotu, pouze vypovida o autorovi, ze si chtel vydelat a ukazat, ze zna nejakou databazi. (Nebo ze by redakce zverejnila clanek, pod nimz flame vyvola vetsi pocet zobrazeni reklamy, zamerne? :-D (Dobre, tak tomu sam neverim...))
btw: Reboot by nebyl potreba, ono by melo stacit zrestartovat daemona a je-li to v PHP i httpd, pak by v cache nemelo byt nic predzpracovaneho z minula.
uživatel si přál zůstat v anonymitě
26. 10. 2005 11:25 Nový

Re: Test?

celé vlákno
reboot som navrhoval z jedineho dovodu ... aby test prveho spustenia bol vzdy testom prveho spustenia (inak povedane ... vycistit diskove bufre)
benzin
benzin (neregistrovaný)
27. 10. 2005 12:20 Nový

Re: Test?

celé vlákno
I kdyz nejsem zastancem C++ s tim pozadavkem bych souhlasil. Tedy do te miry, ze by semlo pristupovat primo k API databaze (a nejcasteji je to C/C++). Jen tezko muzete hodnotit, jestli je rychlost spojena s databazi, nebo s implementaci ovladace pro DB.
Richard
Richard (neregistrovaný)
26. 10. 2005 13:49 Nový

MySQL vs. PostgreSQL vs. Oracle

celé vlákno
Takéto benchmarky sú dosť nezaujímavé a nepraktické. Mám za sebou dosť veľa aplikácií v MySQL, PostgreSQL a v Oracle aby som vedel čo je pre vývoj a nasadenie aplikácií dôležité a čo nie.

Ďaleko viac ako rýchlosť si na databázach cením spoľahlivosť a bezproblematická práca s danými databázami. V 90. rokoch som nedal dopustiť na Oracle ale to bolo v časoch client-server aplikácií, keď bolo dôležité aby server zvládal veľké množstvo pripojených užívateľov a časť logiky aplikácie bola písaná v triggroch a stored procedúrach. V súčasnosti keď sa robia viacvrstvé aplikácie sa celá logika umiestnená na aplikačnom serveri. Použiť stored procedúru je dosť nevhodné.

V súčasnosti ale nevidím ani jednu výhodu Oracle pred MySQL. S Oraclom bývajú niekedy dosť vážne inštalačné problémy, najmä v kombinácii s jeho vlastným aplikačným serverom. Oracle je pomerne dosť veľký žrút zdrojov - zatiaľ čo pri MySQL si môže každý programátor nainštalovať svoj vlastný server na počítač. MySQL má veľmi jednoduché možnosti na export a import (oproti Oracleovskemu exp a imp kde neexistuje jednoduchy export a import dat bez zbytocneho balastu) a pri pouźití ISAM tabuliek je možné si priamo kopírovať data bez ohľadu na OS a verziu MySQL.

Nechcem tvrdiť že MySQL je dokonalá, už ma tiež raz alebo dva krát sklamala ale zistiť kde je chyba a opraviť konfiguráciu je vďaka jednoduchej príručke a širokej komunite jednoduchšie ako v Oracle.

Čo sa týka PostgreSQL tak sa mi zdá trochu nekonzistentná. Ako keby každý programátor PostgreSQL čo mal nejaký nápad tak ho do implementoval bez ohľadu na nejaké koncepčné riešenie (napríklad syntax príkaz v commandline clientovi nemá nič spoločné s SQL). Pri nasadení novej verzie sa mi napríklad stalo, že sa zmenila syntax (pre LIMIT) a musel som v aplikácii opravovať SQL príkazy. Nekonzistetná je aj príručka. Keď som hladal CREATE TABLE tak ako prvú som našiel stránku http://www.postgresql.org/docs/8.0/interactive/tutorial-table.html kde vôbec nie je odkaz na stránku, ktorú som naozaj potreboval: http://www.postgresql.org/docs/8.0/interactive/sql-createtable.html. O problémoch, ktoré boli s inštaláciou predchádzahjúcej verzie na windowsoch by sa dal napísať samostatný článok.

Pri tvorbe ponuke zákazníkom vždy doporučujem MySQL - ale aj tak sa 90% percent zákazok robí v Oracle :)
pavel stehule
pavel stehule (neregistrovaný)
26. 10. 2005 15:27 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
Orientace v dokumentaci chce zvyk, to je naprosto normalni. Souhlasim, ze instalace PostgreSQL na win v cygwin emulaci byl horor, na druhou stranu nikdo cygwin nebral vazne. A fakticky vlastne PostgreSQL na win neexistovala
uživatel si přál zůstat v anonymitě
26. 10. 2005 16:42 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
povodnym vyvojarom liezlo na nervy winapi.

a instalovat server na win? hmm, su jednoduchsie sposoby samovrazdy ...
Michal Kubeček
Michal Kubeček (neregistrovaný)
26. 10. 2005 17:51 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
…a také originálnější způsoby, jak vyvolat flamewar.
honza
honza (neregistrovaný)
26. 10. 2005 15:49 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
[...]V súčasnosti keď sa robia viacvrstvé aplikácie sa celá logika umiestnená na aplikačnom serveri. Použiť stored procedúru je dosť nevhodné.[...]

V diskuzi k mysql na heise.de je asi 80 prispevku k teto problematice. Zhruba 80% respondentu NENI vaseho nazoru. I v jinych diskuznich listech je obdobne mineni. Nezda se Vam to podivne?
uživatel si přál zůstat v anonymitě
26. 10. 2005 16:45 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
stored procedura nie je prenositelna (nie je vygenerovatelna napr z UML somarin).

to je uz zas iny level, tzv biznis level (kasle sa na vykon a spolahlivost, dolezita je nizka cena).

:-)) moderny svet
rezna
rezna (neregistrovaný)
26. 10. 2005 17:31 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
tady si dolovim tezce nesouhlasit ;) - na vykon se sice v urcite mire nehledi, ale hledi se na spolehlivost a hlavne na jednoduchou konfigurovatelnost byznys vrstvy s tim ze pokud mate slusny model ulozeni byznys objektu (napr. XML nebo vlastni textovy format) tak jste schopen z neho generovat i strukturu DB a tim vlastne vydefinovanim jedne vrstvy pokryjete ihned vrstvy 2 coz u stored procedur je trocha mimo ;) - SP maji mozna o neco vyssi vykon ale zase to jejich debugovani je silene a spousta obecnych resenich ktere se v nich pisou je uplne silena.
uživatel si přál zůstat v anonymitě
26. 10. 2005 18:32 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
hej hej, presne toto som mal na mysli.

ono, optimalizacia v konstate je zbytocna, ak vsak takato procedurka prinesie optimalizaciu radu, oplati sa do nej investovat cas (Samozrejme, podla rozpoctu projektu)
rezna
rezna (neregistrovaný)
26. 10. 2005 20:20 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
jasne - pokud SP prinese urychleni z n^3 na n*log(n) - OBRAZNE RECENO - tak ji lze aplikovat - ale jde o to ze min. 90% byznys prace by mela obhospodarovat skutence oddelena byznys vrstva a ne DB protoze co kdyz se v pulce projektu zjisti ze nasazena MySQL nestaci a je potreba neco vetsiho - potom by to bylo dost v pytli byt zavisly na jedne DB
Petr
Petr (neregistrovaný)
27. 10. 2005 18:38 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
Ja to slovo "zrychleni v radu" ctu jako "zrychleni desetkrat" ("o rad"), ne jako "prechod na en-log-en". A musim rict, ze je sakra rozdil, jestli batch job, ktery se spousti denne, bezi tri hodiny nebo tricet hodin.

Psani jednoduche DB vrstvy a slozite aplikacni vrstvy vypada dobre na papire, dokud nezjistite, ze si nejste az tak uplne jistej, co delat s gigabajty dat, ktere byste z databaze musel vytahat a zase do ni vracet. (Samozrejme ted nemluvim o webshopu :-))
ma to
13. 12. 2005 13:53 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
toto je klasicky problem, o ktorom sa vedu dohady ... ci byt nezavisly na DB, alebo nie.
ja si myslim, ze na poriadne aplikacie a vyuzitie prostriedkov _nemozete_ vyvijat bez ohladu na to aku DB budete pouzivat. na papieri to sice moze vyzerat slubne, ale skutocnost je uplne ina a inde.
Richard
Richard (neregistrovaný)
26. 10. 2005 17:49 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
Ne, nezda. Myslim, ze diskusii o databaze sa vacsinou zucastnuju ludia ktori o databazach vedia vela a problemy, ktore ma aplikacia riesit casto riesia prostriedkami, ktore ma databaza. Musim priznat, ze aj som to tak kedysi robil. Ale ak mam business logiku na aplikacnej vrstve, tak nemam vela dovodov pouzit ulozene procedury alebo triggre.
benzin
benzin (neregistrovaný)
27. 10. 2005 11:45 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
Nesouhlasim s Vami. Je to databaze, ktera se stara o konzistenci dat. Pokud tento problem presunete do Aplikace, muze se Vam velmi jednoduse stat, ze nekde neco malo opomeneta a data budou nekonzistentni.

Netvrdim, ze vsechno se musi delat v SP, ale operace, ktere souvisi s konzistenci dat, je nutne delat primo v SP a Triggrech.

P.S.: Casto se stane, ze si zakaznik najme mensi firmicku na sprogramovaniho nejakeho prevodoveho mustku, ten se pak muze rozhodnout pro primi pristup k datum v DB (misto pouziti nedokonalych exportu/importu), paklize nejsou SP a Trigeri udelane spravne, muze se lehce stat, ze se data rozbiji. Pak se muzete dohadovat kde udelali soudruzi z Polske Demokraticke Republiky chybu (kdyz ani nevite, ze vam tam nekdo hrabe primo).
rezna
rezna (neregistrovaný)
27. 10. 2005 11:51 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
pozor ale mluvime jeden o A a jeden o B - jednak se tu resila byznys vrstva - tedy aplikacni logika a ta do DB urcite nepatri, druha vec je databazova vrstva zajistujici konzistenci dat jako jsou spravne FK klice, ukladani kopii radku pri zmenach apod. - tohle do DB urcite patri - do toho by zase byznys logika nemela co sahat...
benzin
benzin (neregistrovaný)
27. 10. 2005 12:15 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
No ale kazdopadne to jasne svedci o tom, ze i vy tvrdite, ze SP jsou potrebne a mely by se pouzivat. A to je zaklad veci (to na co jsou vhodne a na co ne, je jiz vec jina).
honza
honza (neregistrovaný)
27. 10. 2005 12:23 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
a co kdyz se maji ukladat je takove kopie radku, ktere odpovidaji nejake "byznys situaci". Ma se ten trigger pak zeptat te aplikacni logiky, jestli prave dana situace nastala?

Co kdyz je treba pro zjisteni konzistence se preptat u cizich (napr. CAD systemu)?
rezna
rezna (neregistrovaný)
26. 10. 2005 17:36 Nový

Re: MySQL vs. PostgreSQL vs. Oracle

celé vlákno
> a pri pouźití ISAM tabuliek je možné si priamo kopírovať data bez ohľadu na OS
> a verziu MySQL.

mno jasne ISAM jsou super hlavne kdyz se vam snazi dva uzivatele z 6000 snazi pristoupit k jednomu radku tabulku v tom stejnem momentne nebo nedej boze potrebuju rollbacknout transakci ktera tam neexistuje ze ;)
Michal Žeravík
26. 10. 2005 14:26 Nový

FB v produkcnim provozu

celé vlákno
Predem dekuji autorovi za odvahu publikovat takovy flame-nachylny clanek. Vysledky me take vyrazily dech, ps Pgsql nemam zkusenost, ale rikalo se, ze v7 je pomala, v8 je rychlejsi a mysql je nejrychlejsi (aspon v <4.1). Vse ale zalezi na navrhu, indexovani a podobne. Mrzi me jen, ze autor pouzil proprietarni platformu Windows, ktera v mem pripade neni vyuzivana na serverech vubec (ani desktopu :). Na mysql jsem postavil par desitek webu, nejvetsi asi www.depo9.cz . Problemy nastavaji ve spojovani, absenci triggeru a subselectu (v<4.1). Nektere selecty do vice vetsich tabulek jsou i pres indexovani dost pomale. Na FB jsem postavil www.supplypro.de a prace s nim me prijemne prekvapila. Podpora ansisql, vetsina funkci znamych z enterpise databazi, slusna rychlost, podpora charsetu na urovni db atd. Dokumentace je vskutku dost spartanska, nebyt knihy P.Cisare, asi bych do toho nesel. Rozhodne doporucuji FB minimalne vyzkouset.
honza
honza (neregistrovaný)
26. 10. 2005 15:44 Nový

Re: FB v produkcnim provozu

celé vlákno
my mame zkusenosti se zakazniky taky takove, ze jim je jedno vlastne jak funguje ta aplikace (treba jak se zaskladovava) ale rozhodujici jsou ty vlastnosti databaze. Napr.si nedovedu predstavit, kde bychom vzali tu odvahu zakaznikovi rici, ze se pouziva databaze bez ansisql podpory.

Takze tedy souhlas.
benzin
benzin (neregistrovaný)
27. 10. 2005 11:34 Nový

Re: FB v produkcnim provozu

celé vlákno
A take nezapomente, ze se da pouzit jako Embandet a tudiz neni nutno instalovat server a bezi jako bezna lokalni DB. Pro male aplikace naprosto dokalan vec.
uživatel si přál zůstat v anonymitě
27. 10. 2005 13:33 Nový

sekvencie / auto increment

a ako je to so sekvenciami v mysql? viem ze ma nejaky zvlastne fungujuci autoincrement, ale ten nemozem dat na stlpec iny ako primary key a ani nemozem pouzit jednu sekvenciu napr pre vsetky tabulky dohromady (jeden z prikladov pouzitia, poziadavka bola, aby id bolo unikatne v celej db, nielen v tabulke)
geneticy
geneticy (neregistrovaný)
1. 11. 2005 20:39 Nový

To je děs...

Srovnáváte jabka s hruškami a sypete do toho hřebíky ! Ten test na této konfiguraci je naprostý nesmysl a při téhle konfiguraci a nastavení by asi byla absolutně nejrychlejší VFP databáze i nad SQL (a přitom nejde o Db server) s nativním přístupem díky Rushmore indexaci...a možná i ten hloupoučký Access z MS Office.
Tyto testy by se měly provádět zásadně na strojích (HW konfigurace samozřejmě souhlasná) s vhodným OS pro daný DB server, s vyladěným, nikoliv defaultním nastavením a s naindexováním tabulek tím doporučovaným způsobem, jakým pro danou DB je doporučen zkušenostmi/výrobcem. Také syntaxe SQL příkazů musí odpovídat databázovému stroji (ano, máme ANSI SQL, ale žádná databáze na něm ten nejlepší výkon nepodává, každá má své advanced rozšíření). A ani pak se ničeho nedoberete, protože některý systém pro svou perfektní práci prostě potřebuje víceprocesorový systém, HT či jinou věc, nebo jisté minimální množství paměti, protože část DB serverů objekty cachuje (Oracle, MSSQL Ent. třeba views) a to pak teprve sviští, jinak se plouží. Taky jedna věc je nativní přístup k datům z konsoly a jiná věc je aplikační přístup přes prostřednické vrstvy (např. ODBC, OleDB, JDBC atd.). Mizerný ODBC driver vám nezachrání skvělý DB stroj.
Pro rozhodování jakou databázi by neměl být surový výkon hlavním činitelem, ale její vybavení pro daný úkol. Pro bankovní aplikaci těžko zvolíte MySQL, když nutně potřebujete Stored Procedures, stoprocentní referenční integritu, indexovatelné views a transakce. Pak asi sáhnete hluboko do kapsy a vezmete Oracle, DB2, Informix nebo Enterprise MSSQL (podle ostatního vybavení svého systému). Pro webovou aplikaci určenou ke sběru dat a běžící na Linuxu nezaváháte nad MySQL, pokud má umět o něco více, tak PSQL. Pokud potřebujete v MS síti databázi s kombinovaným přístupem web/lokální aplikace/.NET tak asi nebudete váhat na MSSQL, když na to budete mít. Někdy je důležitá rychlost, ale při výkonech dnešních serverů až tak extrémně důležitá není. Mnohdy hraje větší roli její vybavenost a spolehlivost, případně accesibilita z více aplikací/klientů (tzn. vybavenost drivery pro externí přístup) nebo možnost linkovat cizí DB zdroje/servery (nejde o import) do heterogenních datových skladů či schopnosti provozovat OLAP services, při vysokých zátěžích pak třeba pooling a recyklace zdrojů atd.
Myslíte, že monopost F1 by jel na polní cestě rychleji a spolehlivěji než traktor ? Nebo obráceně ? Nebo by jste k odvozu obrovského množství hnoje použili trabant ? A pro nákup do Tesca by jste si zajeli míchačkou na beton ? A na dovolenou na Bahamy by jste letěli na rogallu ? A Lužnici sjížděli na raketovém křižníku ?
Každý DB systém má své místo a porovnávat má smysl JEN v konkurečním nasazení, kdy rozvažujete - stačí mi na ten webový obchod MySQL, nebo to časem rozšířím o on-line platby kartami a prostě se bez spolehlivých transakcí a zabezpeční na úrovni dat již neobejdu ? Těžko budete vnucovat nějakému RM systému řešení na MySQL, stejně jako těžko budete přesvědčovat majitele info portálu s počasím o nutnosti nákupu Oracle, případně těžko budete přesvědčovat firmu vlastnící .NET vývojářský tým, aby přešla na Firebird.
Prostě mi některé nápady připadaly v této diskusi otřesné, promiňte...
Franta Flinta
Franta Flinta (neregistrovaný)
5. 12. 2005 11:29 Nový

Firebird a dotaz na DB

Obavam se, ze tento test neni moc dobre zvladnuty. Jak nekdo prede mnou psal, tak je lepsi mit vice tabulek(naplnenych a spravne oindexovanych) a potom se zacit poustet do nejakych testu a provadet vyber pres vicero tabulek.
Navic konkretne u FB, se kterym mam nejvetsi zkusenosti je zname, ze dotaz volany skrze proceduru je hotov mnohem rychleji nez bezny SELECT na DB.
Svinsva v cteni typu FIRST x SKIP y normalni programator nepouzije! To je zhovadilost na n-tou!
Zatim co nekteri pisou, ze jdou radeji do mySQL pro "mensi" projekty, u nas je to presne naopak. Od mySQL se ustupuje smerem k Firebirdu. Ulozene procedury a triggery jsou veci, ktere posouvaji mySQL(se kterym jsem zacinal) uplne nekam dozadu.
Aktivo
Aktivo (neregistrovaný) ---.87-197-108.telecom.sk
19. 3. 2011 14:13 Nový

Nazov

Najvacsi komfort = PostgreSQL. Firebird a MySQL maju tak 5% moznosti z moznosti ktore ma PostgreSQL. Aj ked Firebird a MySQL su mozno o kusok rychlejsie ako PostgreSQL za ten komfort by som ich nikdy nevymenil.

Zasílat nově přidané příspěvky e-mailem