Názory k článku Otevření 602SQL Serveru: s křížkem po funuse

Opak je pravdou. Ještě jsem se snažil na 602SQL nalézt něco pozitivního, a snad i něco našel (něco málo). To, že 602 je česká firma by nemělo znamenat, že všichni budou nekriticky oslavovat její produkty, v duchu .. není to žádná sláva, ale je to naše. Jinak ten článek je o tom, že v 602 zazdili relativně dobrý produkt, což je pravda, tak není divu, že je k 602 kritický. Dost možná, že nějaká kritika měla přijít o několik let dříve, a v 602 by se snad probudili a postavili na zem.

Ano, prostě jste nenašel nic na webu 602, s vedením 602 jste se nedohodl a tak jste to zpucoval.

Proč bych měl jednat s vedením 602? Nevšiml jsem si, že by v LGPL byla klauzule zakazující hodnocení a testování produktu.

Říká Vám někdo, že byste měl jednat s vedením 602? Já to rozhodně nebyl.

Výrobce operačního systému bude do svého kompilátoru stejně rvát věci, které podporují jeho operační systém. Zkuste si třeba gcc/g++ použít na Windows a jakmile začnete trochu víc ve Windows řádit, zjistíte, že stejně to jde jen s velkým sebezapřením : gcc/g++ nemá třeba SEH (Stuctured Exception Handling) pro kontrolu vyjímečných stavů v programech Windows, nemá zabudovanou podporu COM technologie, nemá x dalších věcí.

Na druhé straně zkuste si třeba Linux jádro přeložit jiným kompilátorem, než je gcc, mám pocit, že to snad ani nejde, protože jádro využívá velmi čile extenze tohoto kompilátoru.

Nakonec stejně zjistíte, že jakýkoli jiný kompilátor, než od výrobce operačního systému stejně jen dohání se zpožděním věci, které pro dobrou a kvalitní podporu toho kterého OS zabudoval do svého kompilátoru výrobce OS. A nevěřte tomu, že 100% možností libovolného OS jste schopní získat jen s normovaným kompilátor bez speciálních rozšíření pro tento systém - to neplatilo ani pro Windows, ani pro Linux, ani pro žádný jiný systém.

Jo jo a nějaké argumenty, kterými byste své tvrzení mohl podložit asi nemáte, co? Sebevědomí Vám jde, tak ještě aby za tím sebevědomím byl nějaký argument a ne jen prázdno.

Chlape chlape, operační systém se na kompilátoru může tvrdě podepsat. Třeba implementace SEHu (ošetřování hw/sw výjimek ve Windows) je značně náročná na kompilátor a s procesorem, ani hw příliš nesouvisí - dostává vnitřní podněty pouze od operačního systému. Stejně tak najdete v běžném kompilátoru tolik věcí závislých pouze na operačním systému, ale které nejde řešit pouze z pohledu hw a procesoru, že to až není hezké. Ne, vyrábět kompilátor bez těsné vazby s operačním systémem znamená vyrobit něco, v čem budete nějak "lepit" a "bastlit" věci, a se kterým bude opravdu hnusné, a v mnoha případech nemožné pracovat.

jj.. watcom to bola klasika.. :-D

Root.cz je periodikum, má ISSN 1212-8309 a také je to jeden ze dvou nejvýznamnějších serverů pro český opensource. Když sem někdo píše, tak je v roli novináře a měl by se podle toho chovat, bez ohledu na to, jestli novinářský průkaz má nebo ne.

Správné by bylo, kdyby ten článek rozdělit na dvě části - jedna by byla "článek" a obsahovala by výčet vlastností, fakta a testy + jejich shrnutí. A druhá část by byla "úvaha" a tam by mohl napsat, že je to sračka a nemá žádnou budoucnost.

BTW: mimo jsi ty, "Nemuze byt akreditovan, neni clenem zadneho svazu..." to jsou podmínky toho, aby byl formálně novinářem. Já jsem ale psal, že je novinářem věcně a tím jsem myslel, že je zde v roli novináře, protože píše článek pro významný český server.

1) S kvalitou i profesionalitou článků na Rootu jsem ve valné většině spokojený a i předchozí články tohoto autora byly v pohodě. Což je důkazem, že i za ten "pakatel" (osobně bych to tak nenazval) se dá napsat slušný článek. Tento ale vybočuje, bohužel směrem k neprofesionalitě, neobjektivitě a zaujatosti.

2) Házet špínu (zvlášť na významném serveru a nazývat to "článek") na někoho, kdo daruje komunitě svoje zdrojové kódy není drzost?

3) Říkat, že programátor, se může chovat jako prase "A programator muze kopat do 602 jak chce" je nesmysl. Ten, kdo píše články (já jim obvykle říkám novináři, bez ohledu na to, jakou průkazku mají či nemají), by měl mít jednak nějaké literální vlohy a jednak svoji odbornost a jednak ctít určitá pravidla. O odbornosti autora pochybnosti nemám, styl by ušel, ale z pravidel porušuje nezaujatost.

To je jako kdybych šel řídit tirák a pak se vymlouval, že neřadím s meziplynem, protože jsem přece programátor a ne profesionální řidič - to je blbost, jsem v roli řidiče tiráku, tak se podle toho musím chovat.

Já si celý článek přečetl a spíše než to co popisujete jsem z něj cítil nejistotu a náměty na to co by bylo třeba udělat aby se produkt jako opensource ujal.

Ale možná jsme každý četli každý jiný článek ;)

Rozhodně mě článek přistrčil blíže k samotnému 602SQL a jsem zvědaví co se s tím bude dál dít. Můj laický dojem z článku je takový, že produkt je hodně použitelný(jako opensource), v pěkném stavu, a že je na něm hodně práce... takže pro případné zájemce z řad vývojářů atraktivní. To že se v něm píše o tom co by bylo ještě třeba udělat (uveřejnit více, informovat o tom co plánují s produktem dále dělat... však to v tom článku je).

Dokonce mě to motivovalo stáhnout zdroják a juknout se na to. :)

Z mého pohledu to kopání určitě nebylo... dík za pěkný článek.

> 2) Házet špínu (zvlášť na významném serveru a nazývat to "článek") na někoho, kdo daruje komunitě svoje zdrojové kódy není drzost?
ne neni, mne chlapci z 602 Software vyhrozovali soudni zalobou, kdyz jsem hexa editorem opravil t602.exe pro dos (blbnul pri praci ze siti) a poslal jim ho.

Jinak produkty 602 byly sice tradicne dost chybovy, ale hodne se prodavaly, mely tlacenku ve vsech moznych institucich a byly velmi popularni zejmena diky lokalizaci. Dneska uz je to historie, ale lepsim vedenim v minulosti by se z 602 dala udelat prosperujici firma schopna mezinarodni konkurence. Rekl bych ze chyba byla zamerit se prevazne na ceskej trh.

Říká se, darovanému koni na zuby nehleď. Možná v tom jsem udělal chybu.

Nemyslím si, že bych házel špínu na Software602. Vše, co jsem napsal, je pravdivé a i snad i politicky korektně napsané. Samozřejmě, že jsem mohl do 602 si kopnout víc, nicméně, to už by mi přišlo nekorektní. Řekněte mi, prosím, co je na tomto článku, případně mých komentářích neobjektivní, nebo nepravdivé.

Pro mne nejdůležitější je kvalita produktu a jeho vlastnosti. Ač tady propaguji PostgreSQL, všimněte si, že neházím špínu ani na MySQL, Firebird nebo Microsoft SQL či Oracle. A neházím špínu ani na 602SQL Server. Pouze vyvracím naprosto nereálnou P.R. zprávu a snažím se najít reálně prostor pro sw o kterém se bavíme.

Ještě jednou, chtněte mne za slovo, prosím, a napiště co je neobjektivní či nepravdivé.

Volkov Commander raději nee - nesahá totiž ani originálnímu Norton Commanderovi, ani M602 ani po kotníky. Volkov Commander měl jedinou výhodu - byl napsán v assembleru, takže byl malý a vešel se snadno na bootovací disketu jakožto nástroj pro opravy / instalace systému. Ale jinak IMHO nic moc.

Ano, naprosto naprosto souhlasím a plně podepisuji. Nemám co dodat. Je škoda, že se ncurses konečně nepošle do stínu zapomenutí, když TurboVision je daleko šikovnější pro práci. A myslím, že i výsledek je lepší a dodělat cokoli v knihovně TurboVision je celkem jednoduché.

Firebird je podstatne lehci nez MS SQL nebo Oracle. Lze jej pouzit i jako server, i kdyz si myslim, ze jako server je PostgreSQL vhodnejsi. Naprosto idealni je ale jako embeded databaze v pripade, ze SQLite by byla prilis jednoducha. Instalace spociva v prekopirovani dvou souboru, databaze se siri binarne a ma platforme nezavisly binarni format. MS SQL, stejne tak Oracle jsou uplne nekde jinde, co s tyce naroku na hw, obsluhu, udrzbu, cenu. Určitě tu budou povolanější, kteří by mohli psát o Firebirdu. Znám pár lidí, co si myslím, že se dokáží racionálně rozhodnout, a ti Firebird používají. Takže bych určitě Firebird nezavrhoval. Zalezi na aplikaci, na pozadavcich zakaznika, atd.

Na Windows jsou i další varianty - například jako embedded databáze se velmi často používá Microsoft Access - mdb formát, který je jedním souborem a lze jej binárně kopírovat.

Jinak sqlite je velice dobrá embedded databáze.

U Firebirdu, jak píšu níže narážím na nedostatečnou (a to je ještě značně diplomatický výraz) dokumentaci.

Na Windows je zase IMHO PostgreSQL nevhodná - v samotném manuálu k PostgreSQL se dočtete něco ve smyslu - jo nějak jsme to na Windows ubastlili, takže PostgreSQL tam chodí, ale nehodláme tomu věnovat čas, Windows verze je zcela na okraji našeho zájmu. A pak člověk zjišťuje, že musí udělat tamto a tohle, a že já si PostgreSQL na svůj noťas prostě nenainstaluji, protože prostě to nejde.

Také si myslím, že stav dokumentace Firebirdu "není uspokojivý". Té, která je volně dostupná na netu. Přeci jenom dokumentace k Oraclu nebo PostgreSQL vypadá jinak.

V PostgreSQL není žádná z podporovaných platforem na okraji zájmu. Řekl bych, že na to, aby 8.3 běžela dobře ve win se věnovalo docela dost úsilí. Na druhou stranu je fakt, že až na výjimky, všichni core hackers jsou srostlí s Unixem, a když už, tak na desktopech mají MacOS. To, že PostgreSQL nelze nainstalovat na všechny win je záměr (a není to tak úplně pravda). Oficiálně lze PostgreSQL nainstalovat pouze na NTFS. S FAT32 nelze zaručit konzistenci databáze. Přesto lze PostgreSQL nainstalovat i na win s FAT32. Pouze initdb je nutné provést ručně. Je to prostě pojistka.

Ještě nedávno byla v PostgreSQL manuálu poznámka, že Windows je pro vývojáře na okraji zájmu, a že se této platformě nehodlají více věnovat. Škoda, že to nemám někde uložené, dnes už to tam není, protože asi někdo poradil, že to není příliš diplomatické.

Ale dnes je tam jen poznámka, že Windows verze má před sebou jen velmi krátký vývoj,m tudíž není otextovaná delším provozem.

To co jste mi napsal je v manuálu. Podle mě to není příliš taktické dělat si z PostgreSQL hogo fogo - on i vývojář potřebuje tu PostgreSQL nainstalovat jako vývojovou verzi pro vývoj třeba na slabý počítač - není třeba stabilita, jen aby se na tom dalo vyvvíjet. Není to příliš taktické takhle postupovat.

Jinak podle PostgreSQL udělalo naprosto kardinální chybu tím, že ignorovalo dlouhou dobu Windows. Protože vidím, že běžné databáze se spíš rozšiřovaly (myšleno procenty rozšíření) z Windows, než z Linuxu. Takový Firebird se třeba také rozšířil z Windows (ačkoli byla Interbase původně naprogramována pro Unix!).

Vedla se o tom celkem dlouha diskuze a volilo se mensi zlo - horsi je, kdyz uzivatel prijde o data, nez kdyz si developer musi rucne spustit skript. Zadna nadutost v tom neni - ovsem jako vzdy, kdyz se vybira varianta typu nejmensiho zla, tak to ma daleko k idealu. Pricina je ale v Microsoftu a ve v implementaci FAT32, nikoliv v PostgreSQL.

To, ze PostgreSQL ignorovalo dlouho Microsoft je fakt, a taky to do jiste miry prispelo k rozsireni MySQL. S Firebirem se PostgreSQL moc neprekryva, aspon mam takovy pocit. Hledal se obchodni model se kterym by se dalo s PostgreSQL uzivit, a jedna varianta byla prodej nativne prelozeneho Postgresu pro win, coz se i jisty cas praktikovalo. Tady je dulezite vzit v potaz. Za Postgresem nestoji zadna firma, tudiz neexistuje nic, co by se dalo oznacit jako dlouhodoba strategie. Urcite neni primarnim cilem ziskat co nejvic uzivatelu. Primarnim cilem je vytvorit kvalitni a spolehlivy produkt, ktery uz si sve uzivatele najde. A dokud se nenasli dobrovolnici, kteri by se chteli portu na win venovat, tak do te doby se neportovalo. PostgreSQL je ciste technicky produkt, projekt ma pouze technicke cile (nebo primarne). Dlouhou dobu vyvojari neverili, ze lze na win bezpecne provozvat db server a jelikoz PostgreSQL bezi ciste jako server, tak nebyl duvod pro portovani. Taky jsem mel na notebooku linux ve wmWare jenom proto, abych mel na cem spustit PostgreSQL.

Firebird je trochu v jine pozici. Dokaze bezet jako embeded db, tudiz byla nutna portace na windows. K tomu interbase je starsi nez PostgreSQL. Zacatkem 90 let tu nebyl free system, a tudiz tehdy port na win byl absolutne nutny. PostgreSQL zacala byt pouzitelna nekdy v roce 98-99, kdy uz byl k dispozici Linux. Navic tu byla obava z uzivatelu windows a z toho, zda budou kapacity na jejich podporu. Cekalo se podstatne vic problemu, vic naborenych databazi, vic otazek ohledne instalaci, atd. Nastesti nebo nenastesti, jak se ukazalo, uzivatelum win byl port PostgreSQL srdecne ukraden. Vetsinou se jedna o vyvojare nebo o studenty. Ja tady v Cechach neznam jedinou provozni databazi na win. Kdo si zaplati win, tak si vetsinou zaplati i MSSQL - aspon zde, kde je Microsoft relativne hodne silny.

Ohledně PostgreSQL už nebudu příliš doskutovat - jen řeknu to, že čestě technické zaměření už zabilo spoustu kvalitních programů a produktů a ještě zabije.

Základní příčina celého problému Windows a PostgreSQL je úplně jinde, a je podstatně jednodušší, pokud můžu sdělit svůj pohled - a to přítomnost nemultiplatformího kódu v jádru PostgreSQL, a ten je tam dosud. Takový Firebird/Interbase vznikl na Unixech, bez problémů předělal konverzi na Windows a zase zpět na Unixy - a neměl s tím přílišný problém, protože kód byl napsán kvalitně a multiplatformně. PostgreSQL takto kvalitně multiplatformní kód napsaný nemá - a tudíž má na neunixové platformně o několik řádů větší problémy, než třeba Firebird. Koneckonců před několika lety vývojáři Postgresu tento fakt přímo sdělovali a Windows verze byla plná knihoven emulujících řadu věcí z Unixu. Viděl jsem zdrojové kódy jádra PostgreSQL a viděl jsem tuto situaci také.

Jinak ať už jsou technické důvody jakékoli - a ať vývojáři třeba zaspali dobu a příliš přísně hledí na to, která platforma je a není vhodná pro db, jsem pevně přesvědčen, že kdyby PostgreSQL dala včas port na Windows, její rozšíření dnes (a kdykoli v budoucnu) je o několik řádů vyšší, než v současné době. A jsem přesvědčen, že tento fakt (zaspání doby a příliš suše technický přístup vývojářů k jakémuko situaci) nakonec v nějaké střednědobé variantě zlomí PostgreSQL krk a za takových pět let plus mínus PostgreSQL prakticky zmizí z povrchu země. Ale toť jen můj subjektivní názor, kterému se klidně můžete zasmát. Vzpomeňte si pak na mě.

Interbase/Firebird je databáze, která hlavně měla to štěstí, že jí koupil Borland. Kromě toho, že Borland jí naportoval z unixů na nejpoužívanější platformy tehdejší doby (Netware, Windows) a vylepšil jí (například stored procedures v Interbase jsou z dílny Borlandu), hlavně zařadil Interbase do Borlandích tehdy velmi velmi populárních RAD nástrojů. Tím pro její propagaci a rozšíření mezi běžný lid udělal nesmírně mnoho. Později, když Borland začíná být za zenitem své slávy, ale stále ještě dost silný, opět udělal pro rozšíření Interbase šťastný krok - uvolnil jí jako open source. A Interbase měla štěstí - zrodil se Firefox později přejmenovaný na Firebird.

Netuším, co bude za pět let, možná že už Postgres 9.x a Firebird 3.x. Jedinou chybou, co se týče portability, Postgresu, je závislost na Locales. Jinak je pg portovatelné docela dobře. MySQL, stejně jako Firebird nejsou závislé na locales, tudíž jsou snáze portovatelné. I k tomu snad během následujícího roku dojde u Postgresu (spojeno s podporou COLLATES, která dost chybí).

Že by Postgres do pěti let zmizel, možná, pokud Oracle nebo Microsoft začnou svoje databáze distribouvat pod GNU nebo BSD licencí. Jinak těžko. V Japonsku nebo Rusku je např. používanější než MSSQL. Jinak Postgres nemůže dost dobře konkurovat mezi běžným lidem Firebirdu. Na to je příliš těžká váha a Firebird více-méně je už zaběhlá značka, která funguje a dělá, to co od něj běžný lid chce. V ToDo PostgreSQL je jeden důležitý bod: PostgreSQL nikdy nebude embeded databáze, tudíž v celé řadě nasazení nikdy nebude moci konkurovat Firebirdu nebo SQLite. A naopak Firebird díky svému podstatně širšímu záběru patrně nikdy nebude moci konkurovat PostgreSQL (To nikdy, je spíš horizont 10 let, co bude dál si netroufám odhadnout ,, tou dobou, už bude docházet ke generační výměně minimálně core hackers).

Ad první odstavec - jsem programátor s dvacetiletými zkušenostmi, a kód Postgresu jsem viděl, takže mi dovolte abych Vaše první věty považoval za ne zcela přesnou infomaci, řekněme, že jste trochu větší optimista. Úhybný manévr se svedením na locales už nebudu komentovat.

Lidé jako Vy se nedokáží představit, že rozšíření (a tedy i bytí a nebytí) produktu, či programu by mohlo záviset, a zpravidla závisí daleko více na netechnických věcech, než na technické kvalitě programu. Historie dává nesčetné příklady, takže se nebudu opakovat. Jen říkám, že za dvacet let co se aktivně věnuji IT (zdaleka nejsem nejmladší) vidím nespočet příkladů, jak podobná strategie jako má PostgreSQL poslala program do zapomnění.

Nikdo po PostgreSQL nechce aby byla embedded. Jinak dovolte mi jeden postřeh - kdykoli se mluví o PostgreSQL, tak jí chválíte a bráníte zuby nehty aby na ní nezůstal ani stín ani podezření špatného, a oproti tomu do kontrastu jak jste docela zpucoval 602SQL mi nějak evokuje závěr, že neposuzujete věci až tak docela nestranně.

Naprosto s Vámi souhlasím, že bytí a nebytí produktu nezávisí jen na technických věcech, a také bych mohl uvést dost příkladů. A je také možné, že Postgres časem zmizí. A možná to bude z důvodu špatného marketingu (resp. žádného nebo minimálního). Nicméně zatím strategie vývojářů - soustředit se na svojí práci - vychází. Co bude za rok, za dva netroufám si tipovat.

Když Vám databázový server během jednoho dne na jednoduchých dotazech a relativně malé testovací množině dat (100 000 záznamů) několikrát tiše spadne, tak si o něm nemůžu myslet, že je vhodný pro náročnější aplikace. Samozřejmě, že vidím do projektu PostgreSQL, znám důvody proč něco v pg je a něco není (k dispozici je archiv konference za posledních 10 let - takže kdokoliv si může zjistit potřebné informace). O pozadí 602SQL vím jenom z informací na webu a netu.

Mám ale pocit, že se tady bavíme o něčem jiném než o objektivním hodnocení nějakého díla. Dovolil jsem si hodně, kritizovat idol. Jenomže ten idol stojí na hliněných nohou. Mimochodem, mě přijde zajímavé, že tu 602SQL nebrání žádný uživatel, který má praktické zkušenosti, který tento server používá. Samozřejmě, že by ten mojí kritiku dokázal věcně komentovat.

p.s. Všimněte si, že tu zuby nehty nebráním jen PostgreSQL ale třeba Firřebird nebo MySQL. Nesnáším totiž FUD. A to, co jsem o 602SQL napsal, jsem si předtím otestoval.

Ale ano, souhlasím s Vámi v leččems ohledně 602SQL, a souhlasím s tím, že tato db se měla uvolnit o několik let dříve, a měla by daleko větší šance. Nikdo tu nemluví o idolu, ale jen se tu já a několik lidí ptá - jak moc je Vaše zpucování dáno z věcných důvodů a kolik je v tom emocionálních, tedy osobních důvodů (ať už naštvání z P.R. firmy 602, což přiznáváte, nebo nekritický obdiv z PostgreSQL a nebo něco jiného). Nic konkrétního nenaznačuji, ale prostě formulace toho článku ve mě budí opravdu dojem, že Vám 602 něco špatného provedla. Přesto vše jsem ochoten uznat, že 602SQL má v současnosti našlápnuto opravdu velmi špatně a pokud se nestane zázrak, asi je tohle její poslední štěk.

Mě se abych se přiznal Vaše hodnocení žádné db moc nelíbí. Každá db má své stinné a slabé stránky - a je jedno co vyberete. Každý programátor potřebuje nutně znát obě strany mince. Mě se velmi líbil příspěvek pana Císaře, který byl prostě věcný, jasný a bez emocí - ano, Firebird v této oblasti dokumentace není ideální, ale řeší se to takto a takto - a lze udělat to a to. Skvělé, přesně toto mi vyhovuje. Zatímco u Vás, nemohu si pomoci vidím při psaní o db značný emocionální vztah, který se promítá do psaní o db, a ten moduluje Vaše příspěvky tak značně, že je třeba s tím počítat.

Nicméně jste podle přspěvků odborník na svém místě, máte značné zkušenosti a rád si přečtu jakýkoli další Vás článek, nebo příspěvek - a vím, že mě to obohatí. Chci Vám za Vaše příspěvky i článek poděkovat, protože patří k tomu nejlepšímu, co mohu číst.

Jenom pro záznam. S Software602 jako firmou nebo lidmi v pozadí nemám a neměl jsem nikdy žádný konflikt. Ani osobně neznám nikoho z Sw602. Z produktů 602 jsem používal Microbaze Pascal, t602, Calc602. Na Microbáze Pascal dodnes nedám dopustit.

Problém Firefoxu hlavně je, že je to černá skříňka. Neexistuje k tomu pořádná dokumentace, a to ani pro nejzákladnější věci. Na jedné straně se vytýká 602SQL v článku nedostatek dokumentace (čímž nehájím 602SQL), na druhou stranu se chválí Firebird, kde je dokumentace na tak mizerné úrovni, že jsem snad hůř zdokumentovaný projekt neviděl. Těžko říct co je u něho featura a co chyba a jak se to má v jemných detailech vlastně chovat, když prostě dokumentace je mizerná (a derou se mi na jazyk ohledně dokumentace Firebirdu daleko daleko ostřejší výrazy). To je jeden z důvodů proč Firebird moc nepreferuji.

Ze stejného důvodu je jasné proč Firebord asi bude chybovější, protože bez dokumentace nelze spoustu věcí vytušit, nelze ani je zkontrolovat a poslat případné bug reporty.

Vsadím se, že i pro teb 602SQL je dokumentace na podstatně lepší úrovni, než to co je k dispozci pro Firebord.

Předesílám, že jsem neviděl placenou dokumentaci k Firebirdu. Co se týče on-line dokumentace, tak těžko soudit. Dokumentace u 602SQL nejde nijak do hloubky ani do šířky, ale je kompletní a česky. K Firebirdu. Některé části dokumentace jsou na úrovni, jiné zase naprosto chybí (a to zásadní věci :(). Ovšem je tady výborná kniha Pavla Císaře. Pavlova kniha je podstatně lepší než dokumentace v 602SQL .. obsahově, stylisticky .. vůbec je to povedená kniha (řekl bych, že je i o dost lepší než Bruceova kniha o PostgreSQL). To, že Firebird nemá kvalitní dokumentaci volně přístupnou může schíza v projektu, kdy část je free a část placená. V každém případě, pro Fb existují referenční projekty, pro 602SQL nikoliv. To je zásadní rozdíl. Jinak samozřejmě, že kvalita dokumentace hraje velkou roli.

Knihu Pavla Císaře jsem viděl - ale rozhodně nemůžu už z principu rozsahu popisovat chování Firebirdu do hloubky, může vysvětlit jen základní věci. Za druhé kniha zastarává a nemůže reflektovat současný vývoj Firebirdu. A žádná kniha nemůže nahradit oficiální dokumentaci.

Dobrá, existují referenční projekty - takže prakticky metodou "téměř reverzní inženýrství" se dozvíme něco o Firebirdu?

Ne, ne, jestliže kritizujete dokumentaci k 602SQL, je třeba pořádně zpucovat i dokumentaci Firebirdu. Protože Firebird si to více, než zaslouží. Znovu opakuji, že horší dokuentaci k projektu, než je u Firebirdu jsem neviděl.

Dnes jsem si vzal na paškál 602SQL Server. Firebird se k tomu připlet nenápadně, když jsem do diskuze napsal, že jsem na internetu našel poznámku o vynuceném a úspěšném přechodu z 602SQL na Firebird. Když budu propírat Firebird, tak na dokumentaci určitě nezapomenu (pokud se to nezlepší) :).

S volně dostupnou dokumentací k Firebirdu je opravdu problém. Ne že by jí nebylo dost, spíše naopak, ale není nijak ucelená. Ucelenější dokumentace je bohužel zatím jen placená. Už pár let je k dispozici na našem DevCD "Using Firebird", "Firebird Reference" a hromada specializovaných dokumentů (např. jak psát externí funkce, rozbor optimalizátoru, analýza výpisu LockPrint, interní struktury databáze apod.). Mimochodem DevCD se dá koupit nejen samostatně, ale je součástí služby Subscription (něco jako MSDN pro Firebird), takže aktualizace dostáváte automaticky 3-4x za rok. Před rokem a něco jsme obě hlavní knihy uvolnili k volnému použití v rámci projektu Firebird, a subprojekt pro dokumentaci na nich pracuje (převod do docbooku, aktualizace, restrukturalizace atd.). Bohužel jde práce pomalu, je málo lidí a dokumentace má cca 1500 stran, takže k dispozici je zatím jen pár kapitol, zato existují překlady do různých jazyků.

Absolutně nejlepší dokumentací je The Firebird Book od Helen Borrie, cca 1200 stran. Bohužel neobsahuje kompletní přehled příkazů (už by se nevešel, i takhle už má kniha pár kilo), takže je vhodné ji doplnit o "Firebird Reference" nebo moji knihu která seznam příkazů obsahuje. Zato obsahuje např. popis systémových tabulek, seznam chybových kódů apod. které třeba v mé knize nejsou.

Co se týče dokumentace k aktuálním verzím, tak Release Notes jsou velmi dobře udělané, vyčerpávající a přehledné.

Co se mojí knížky týče, tak jsem si jejího zastarávání velmi dobře vědom. Pokud bude mít Computer Press zájem, tak bych příští rok rád udělal aktualizované vydání, nebo spíš přepracované vydání. Nejradši bych vysekal InterBase a zaměřil se jen na Firebird (kvůli přehlednosti), přečesal jako knihu o Firebirdu 2.1 (vykašlat se na členění co není podporováno u starších verzí kvůli přehlednosti a úspoře místa pro jiné věci), zvětšil počet stran alespoň o 200 a vypustil CD (kvůli ceně knihy, zvyšuje ji o cca 50 Kc). Bohužel vše záleží na zájmu CP, a psát to celé znova a jinak pro jiného vydavatele fakt nehodlám.

Jinak bych rád věděl, jaké věci probrané "do hloubky" vám k knize chyběly (případně jaká hloubka je pro vás dostatečně hluboká). pokud to půjde, rád je do nové verze zapracuji.

Děkuji moc moc za tento příspěvěk, hodně věcí jste mi objasnil a nasměroval mě. Děkuji mnohokrát.

Nemyslel jsem to tak, že bych z referenčních projektů reverzním inženýrstvím zjišťoval API Firebirdu - což jsem začátkem 90 let zrovna dělal s Excelem 5.x. Pokud Vážně uvažujete o projektu nad Firebirdem, tak se vyplatí ty peníze za dokumentaci dát. Horší je dokopat se k tomu, aby ji člověk přečetl. Ale to je problém spíš Firebirdu a jeho komunity. Drobet to kazí první dojem z Firebirdu.

Měl jsem na mysli něco jiného. To, že pro Firebird existují referenční projekty, dokazuje, že někdo dokázal s Firebirdem vyřešit všechny problémy a dotáhl projekt do konce. A to je pro mne důkaz, že se s Firebirdem dá vyvíjet a nad ním provozovat aplikace. Například Pražská městská knihovna jede nad Firebirdem, nějak, ale jede. Nic takového pro 602SQL neexistuje. Vzhledem k tomu, že 602 posílá do světa méně významné informace, dá se předpokládat, že žádný takový projekt neexistuje. Buď se o to nikdo nepokusil, nebo se to nikomu nepodařilo. V tom je podstatný rozdíl mezi Firebirdem a 602SQL.

Opět kopete do 602SQL :-) Nikoli, v 602SQL bylo docela hodně projektů - a znám lidi, kteří s ní dost dělali. 602SQL byla velmi velmi príma v době, kdy to nebyla jenom databáze, ale kompletní databázové vývojové prostředí i s programovacím jazykem na bázi Pascalu a možností velmi šikovně a jednoduše napsal rovnou i db klienta. Dokonce to bylo přenositelné na Windows i na Linux - a tehdy byla 602SQL velmi velmi silný produkt, který neměl a nemá konkurenci v oblasti RAD vývoje pro databáze a velmi připomíná Microsoft Access s jeho možnostmi. Tehdy se aplikace kolem 602SQL serveru vyráběly jak na běžícím pásu a bylo to velmi rychlé a kvalitní - super a bezkonkurenční.

To neznamená, že když je firma 602 Software marketinkově totálně neschopná, že její produkty nemají uplatnění. Mezi jejími produkty jsou i totální propadáky a její strategie není zrovna moc šikovná, ale má za sebou několik dost dobrých věcí. Problém Váš i tohoto článku je, že když prostě neschopní lidé Vám nedají informace, že pak vylijete s vaničkou i dítě.

Naopak, pokud by firma 602 Software opravdu uvolnila 602SQL kompletní prostředí se vším všudy, jak jej kdysi prodávala jako balík 602SQL, tak byste získal naprosto bezkonkurenční nástroj - ve kterém i dítě, nebo začátečník v cukuletu a ve velmi velmi krátké době vyrobí kvalitní databázovou aplikaci - se serverem i databázovými klienty pouze prostředky 602SQL balíku. V této oblasti to kromě Microsoft Accessu naprosto nemá konkurenci - nic podobného nikde neexistuje.

Diskutujeme o 602SQL Serveru počínaje verzí tuším 8. Pro starší verze, tuším, že zdrojové kódy nebyly uvolněny (alespoň nejsou ke stažení na source forge). Jinak WinBase je dávno historií stejně jako je FoxPro, Paradox, PC Fand. Historický přínos 602 jsem zmínil :)

K čemu je Vám bezkonkurenční GUI, když máte postarší db jádro? Dneska je k dispozici dost GUI designerů, které s dobrým sortimentem komponent bezproblémově nahradí jednoúčelové 4GL databáze.

Jmenujte prosím Ty GUI designéry, které umožňují rychlý vývoj db aplikací. Pak je postavte třeba vedle Microsoft Accessu, a velmi mě zajímá, kdo vedle toho dopadne dostatečně dobře. Nic moc.

Ve win především Visual Basic nebo dneska Visual Studio. Access znám. Vím, že se s ním dá dělat docela dost věcí, a že jednoduché věci se naklikají docela rychle. Problém je pak takovou aplikaci udržovat a rozšiřovat. Sám jsem přepisoval dvě takové aplikace. Odbočím - v každém případě, když už byla databáze v Accessu, tak to bylo terno. Setkal jsem se s docela velkýma db aplikacema v Excelu. Ale abych jenom nehanil. Jako interface byl Microsoft Access k Microsoft SQL Serveru vynikající. Samozřejmě, jak pro Visual Basic tak pro Visual Studio bylo potřeba dokoupit komponentu, v které by se daly dělat reporty.

Pro Linux .. Gambas, Lazaurus, Mono Develop (to spíš teoreticky), Eclipse, QT Designer. Jestli snesou srovnání? Těžko říci. Já osobně bych Ms Access, FoxPRO už nepoužil. Přičemž si dovolím tvrdit, že jak MS Access, FoxPRO jsou výborné produkty. Nicméně db aplikace se už teď píší přeci jen v něčem jiném.

V Accessu se nemusí klikat a ne vždy je to nejefektivnější cesta. Není problém udržovat dobře napsanou aplikaci v Accessu. Já znám taky pár prasecky napsaných aplikací třeba v C, v C++, i v mnoha dalších jazycích a nedělám z toho hned závěr, že daný jazyk je takový, nebo makový.

Tak jo, sedneme si - já budu mít v ruce ten Access a vy cokoli jiného. Zasoutěžíme si, ano? Nemůžu prohrát. Microsoft Access je výborný produkt a svoje použití rozhodně dnes najde. FoxPro je produkt minulosti.

V práci máme taky projekt nad Firebirdem, jde o systém pro výpočet a výplatu sociálních dávek. Ve stručnosti jde o výpočet výše dávky nebo důchodu dle vstupních dat (započtené doby, kategorie, služební poměr a tak) a těchto v současné době cca 50000 dávek každý měsíc vyplácet (což je vypočítat sumu, z toho vyplatit případné soudem nařízené srážky, výživné, obstávky nebo pohledávky a nakonec vytvořit soubory pro poštu a banky). V ostrém provozu to běží asi 2 roky plus je do databáze naimportována z původní DOSové aplikace historie plateb za cca 10 let zpátky, s databází pracuje kolem 60 lidí a nutno říci že jsme maximálně spokojení a ani na problémy popisované zde v diskuzi jsme nenarazili (třeba to padání pod Linuxem, používáme verzi Classic sám server nespadnul, pouze s mou pomocí když jsem ladil UDF a špatně jsem vracel návratovou hodnotu).

Takže neřekl bych, že Firebird je dobrý hlavně jako embedded databáze, jdou v tom dělat i velké a při tom spolehlivě fungující projekty. Ale je pravda, že máme dost zkušeností ještě s původní Interbase od verze 4 (byla v Delphi 3), pak přes 5.5 a 6 jsme přešli na Firebird. Dokumentaci jsme měli tištěnou k té verzi 5.5, pak k verzi 6 byla beta v pdf a po přechodu na Firebird nám stačila kniha od Pavla Císaře a s novou verzí si přečíst release notes. Ale je pravda, že kdybych o Firebirdu nic nevěděl a chtěl začít se současnou verzí, asi by mě odradilo číst pdf k Interbase 6 a pak release notes ke každé verzi Firebirdu.

Ano a jakmile se objeví další verze Firebirdu, tak si koupíte za další 3k další verzi dokumentace? Skvělé.

Firebird naopak vcelku preferuji, s pgsql jsem potkal osklive problemy s vacuem a prateli (a predevsim mam nejake apocalypticke reporty od kolegy, typu zmeny defaultni verze hodnoty pro autocommit v minor releasu, ale to je z druhe ruky). To už je hodně dávno. :) Mám pocit, že to bylo v 7.3 nebo v 7.2 a taky se na to celkem dlouho vzpomínalo (jako na pořádný malér). Šest let zpátky.

A není to smutné, že ještě v sedmé verzi programu jsou naprosto zásadní chyby?

Bylo to zhruba tři roky po zahájení projektu. S číslováním je to u PostgreSQL docela legrace. Byla verze 95, pak 1.0, a pak rovnou 6.0. Přičemž se přebíraly a překopávaly zdrojáky z čistě akademického projektu s experimentální podporou SQL. Jinak chyby byly a budou. Nepřiznat si to by bylo dost pokrytecké. Důležité je, aby měli minimální dopad na uživatele a byly co nejrychleji odstraněné.

A on snad někdo říká, že v programech nejsou a nebudou chyby? Kde to prosím píšu? Mluvím o tom, že pokud někdo označí program jako sedmou verzi a ten program obsahuje ZÁSADNÍ CHYBY (všimněte si zásadní, opakuji to abyste si toho všimnul), pak něco moc moc smrdí. Do kontrastu kdy obrovská spousta programů ve verzi 0.něco je prakticky použitelná a bez zásadních chyb. I když se číslovalo divoce, pořád je sedmá verze několikátá major verze v pořadí.

Jednalo se o zásadní chybu, nikoliv chyby, a jednalo se chybu v konfiguraci nikoliv v kódu - změnil se dafault. Číslování v o.s. nehraje roli - záleží na stáří systému. Jestli někdo přičítá po 1.0 a někdo po .01. Kdyby u Firebirdu nedošlo ke změně jména, tak by byl dnes Firebird 9.x. Tady nechápu, co chcete říci.

Chci tím prostě říci, že tohle by se stávat nemělo a nemělo by se to omlouvat.

Shodou okolností jsem v c602 také něco dělal, a že by c602 běhalo rychle si nemyslím. c602 byl unikátní integrací S-Pascalu, v době Excelu 4.x to byla něco nového. Nicméně např. ve srovnání s Quatro Pro to byl šnek.