Zobrazení zdroje stránky 602SQL Server

==S křížem po funuse (aneb otevření kódu 602SQL Serveru pod LGPL)==
Překvapivé [http://www.602.cz/cz/o_firme/tiskove_zpravy/602sql_open_server_je_nyni_volne_k_dispozici_pro_komercni_i_nekomercni_pouziti prohlášení] 602Software o [http://sourceforge.net/project/showfiles.php?group_id=203848 otevření kódu] [http://www.602.cz/cz/produkty/602sql_open_server_11_0 602SQL Serveru] je patrně jedou ze zásadních událostí na domácí IT scéně. Je to důležitý precedens. 602SQL Server je ukázkou, jak relativně kvalitní produkt díky špatnému marketingu a nedostatečné podpoře nedokáže držet krok s konkurenčními produkty a posléze ani s open source konkurencí. Otevření kódu v případě 602SQL Serveru bohužel přichází pozdě, kdy je jen malá šance na jeho revitalizaci.

==S křížem po funuse (aneb otevření kódu 602SQL Serveru pod LGPL)==
Se jménem RNDr. Januše Drózda jsem se poprvé setkal ještě v osmdesátých letech, kdy ještě spolu s Petrem Coufem napsali překladač a prostředí tzv. Mikrobáze Pascalu pro ZxSpectrum. Bylo to v roce 1986 a byla to absolutní bomba. Prostředí MB Pascalu bylo na poměry ZxSpectra nadupané funkcemi. Škoda, že už nepřepsali MB Pascal pro Didaktik Gama, který přeci jen měl o 32K paměti víc. S tím už by se daly dělat věci. Nebudu asi jediný, kdo díky jejich práci, zůstal u počítačů a živí se v it. Pak už přišlo CP/M s TurboPascalem 3.0, poté první PC a přelomové verze Turbo Pascalu 5.0 a 6.0. Zřejmě to nebyla náhoda, že první produkty 602 měly integrovaný Pascal. První funkce v S-Pascalu jsem napsal v Calc602, což byl na svou dobu docela progresivní spreadsheet. V devadesátých letech začal 602 ujíždět vlak. Calc602 byl první tabulkový procesor s integrovaným plnohodnotným jazykem, ale byl a zůstal pouze ve verzi pro DOS a byl neskutečně pomalý. Co se dělo v té době v 602 nevím, pro mne naprosto nepochopitelně 602 postupně vyklízela veškeré pozice. Produkty, které byly uvedeny na trh, byly uvedeny pozdě a za naprosto nesmyslné ceny (v cenových relacích ne nepodobných Microsoftu). V 602 si až příliš pozdě všimli, že existují Microsoft Windows, a později, opět, podcenili konkurenci Open Source. Na RNDr. Januše Drózda nevzpomínám z návalu nostalgie, ale proto, že je jedním z autorů 602SQL Serveru - SQL RNDBS, jehož kód byl minulý týden otevřen pod licencí LGPL.

Podle optimistického vyjádření obchodního řiditele 602 je otevření 602SQL Serveru pod LGPL dlouho připravovaným krokem, který má zajistit produktu další vývoj. 

<i>„Uvolnit software do open source není tak jednoduché, jak by se mohlo na první pohled zdát. Zdrojový kód je naší vizitkou a jakákoliv nešikovnost nebo dokonce chyba by byla okamžitě veřejně viditelná. A samozřejmě, že jsme zvažovali i obchodní stránku věci. Ale jsme přesvědčeni, že to bylo rozhodnutí potřebné a správné. Globální komunita open source je obohacena o dobrý databázový produkt, prestiž českých vývojářů dále vzrostla a práce tisíců IT expertů celého světa zajistí produktu další rozvoj. To je kombinace, na níž nakonec vydělají všichni zúčastnění,“</i> řekl obchodní ředitel Software602 Ing. Pavel Nemrava.

[[Image:602SQL.png|thumb]]

Nejsem tak optimistický. Nevím, ale obávám se, že Ing. Nemrava zažije nepříjemné zklamání. IT expertů, kteří se účastní vývoje open source databází, rozhodně nejsou tisíce. Vývojářů Firebirdu je něco kolem desítky, PostgreSQL je výsledkem práce zhruba max. třech desítek lidí z celého světa a řekl bych, že podobně na tom budou u MySQL. Kdyby k otevření kódu došlo před čtyřmi roky, tak by možná 602SQL Server mohl přetáhnout vývojáře Firebirdu nebo PostgreSQL a zaujmout snad lepší  postavení. Nemyslím si, že by kdokoliv dnes investoval do vývoje dalšího databázového serveru. Ještě před čtyřmi lety byla jiná situace. Stejně tak pozdě přišlo otevření SAPDB a Ingressu. A je mi to, přiznám se, docela líto. Na to jaké má 602SQL Server nároky, toho umí fakt hodně. Implementace SQL respektuje standard, je konzistentní a úplná. GUI je praktické a funkční. Není mi známo, kolik vývojářů stojí za 602SQL Serverem, odhadoval bych to tak na 1-3, což opět nedává 602SQL příliš šancí. Poslední tři verze byly víc zaměřené na klientské rozhraní a na opravu chyb než na databázový engine. Každý si musí udělat jednoznačný obrázek při porovnání Release Notes 602SQL a PostgreSQL, Firebirdu nebo MySQL. Ono se toho ale v málo lidech příliš udělat nedá.

Jako největší mínus vidím dlouhodobě špatnou podporu z 602. Oficiální fórum má poslední odpověď Jana Šímy z června 2002. Neoficiální fórum uživatelů na pandoře.cz stále žije, nicméně podle počtu příspěvků je zřejmé, že zenit 602SQL Serveru byl v roce 2003. 
<pre>
1999 (3)] [2000 (0)] [2001 (0)] [2002 (189)] [2003 (306)] [2004 (107)] [2005 (58)] [2006 (19)] [2007 (32)] 
</pre>
Druhé a zásadní mínus, pro open source vývoj, je nedostatek (resp. neexistence) vývojářské dokumentace. Nikde jsem nenašel popis zpracování dotazu, popis architektury, datového formátu, atd. Buďto neexistuje, a nebo tuto dokumentaci 602 nechce zveřejnit. Bez této dokumentace není pravděpodobné, že by se někdo vážněji 602SQL Serverem zabýval. Zdrojový kód je docela hutný a bez znalosti interních mechanismů nedešifrovatelný. Hádám, že minimálně 30% komentářů je v češtině. Tudíž potenciální vývojáři se musí rekrutovat z Čech nebo Slovenska. Kdo zná zdejší komunitu, ví jaký je tu nedostatek vývojářů. 

Databázové produkty 602 trpí nekoncepčností. Nejdříve tu byl klasický relační databázový systém 4GL, poté databáze, která se snažila o symbiózu jak 4GL architektury, tak architektury klient/server a nakonec 602SQL Server je ukázkovou aplikací klient/server. To, že 602SQL Server přišel o 4GL vlastnosti hodně uživatelů nepochopilo a odmítlo. To, že 602 se snažila o prosazení vlastního prostředí pro vývoj www aplikací, jsem zase nechápal já. V době PHP nebo ASP neměli šanci, bez ohledu na to, jak kvalitní jejich návrh byl. 

Ze zvědavosti jsem si 602SQL Server nainstaloval a dva dny jsem si hrál. Test na vyhledávání prvočísel není typickým databázovým testem, ale generuje velký počet triviálních příkazů SELECT a DELETE. Pokud používáte triviální nebo jednoduché SQL příkazy, pak v reálné aplikaci (v jednouživatelském režimu) nikdy nebude rozdíl mezi databázovými platformami větší než jaký ukazuje tento test (PostgreSQL je jednou tak rychlejší co 602SQL Server, což je). Test pgbench testuje průchodnost serveru ve víceuživatelském prostředí, obsahuje jak dotazy na data, tak změny dat. Netýral jsem 602SQL Server komplikovanými SQL dotazy .. vzhledem k tomu, že jeho query planner není postavený na posouzení nákladů na provedení dotazu, by byl 602SQL Server těžce znevýhodněn vůči PostgreSQL. Obdobný Q.P. měly i starší verze Firebirdu a MySQL. Současné verze mají podobně navržen Q.P. jako PostgreSQL. Jaký typ Q.P. má 602SQL Server skutečně, jsem se nikde nedozvěděl. To, že se jedná o první generaci Q.P. spíš odhaduji z neexistence statistik. 

Testovací příklad (určení prvočísel):
<pre>
FUNCTION siete( ) RETURNS integer; -- zde podle ANSI SQL nemá být středník (snad 
BEGIN                              -- jediný prohřešek standardu)
  DECLARE _f integer;
  DECLARE _l integer DEFAULT 1;
s_loop: 
  LOOP
    SET _f = (SELECT MIN(a) 
                 FROM numbers
                WHERE a > _l);
    IF _f IS NULL THEN LEAVE s_loop; END IF;
    DELETE 
       FROM numbers
      WHERE a MOD _f = 0 AND a > _f;
    SET _l = _f;
  END LOOP;
  RETURN (SELECT COUNT(*) 
             FROM numbers);
END;
</pre>
S dalším testem bylo víc práce.  Aplikační rozhraní 602SQL Serveru se dost liší od API PostgreSQL. Ovšem výsledky mají, pro mně, podstatně vyšší váhu než určování prvočísel. Díky pgbench testu si lze ověřit průchodnost databáze při vysokém zatížení v typizovaném podnikovém prostředí. Výsledky ukazují, že 602SQL server drží krok s Postgresem pouze v případě menším počtu transakcí na spojení a při malém počtu klientů (a pokud se nevynucuje zápis změn při commitu). Tady je třeba konstatovat, že pouze vynucený zápis změn při commitu zaručuje konzistenci databáze, a že výchozí nastavení 602SQL Serveru není bezpečné. 

<pre>
1 klient	                1Kt	5Kt	10Kt	
602SQL Server 	 fsync = off    1.2s	16.5s	1m51.1s	
		 fsync = on	9.0s		2m20.6s

PostgreSQL 8.3	fsync = on	1.4s		13.6s

klientů (1000 transakcí)	1	3	10
602SQL Server	fsync = off	1.2s	3.7s	29s
PostgreSQL 8.3	fsync = on	1.4s	3.7	14s
</pre>

Samozřejmě, že to není fér vůči 602SQL Serveru (I když verze 11 je v podstatě pouze o půl roku starší než PostgreSQL8.3). Multi generační architektura PostgreSQL je při více uživatelském přístupu zásadní výhodou. 

Plusy a mínusy na které jsem narazil:

Plusy:
* přitažlivé prakticky navržené jednoduché administrativní prostředí,
* konzistentní a dostatečně široká podpora SQL respektující standard,
* jednoduchá administrace (v podstatě není co konfigurovat),
* česky psaná dokumentace (psaná víc pro programátory než pro DBA),
* fulltext podporuje češtinu (podpora COLLATES je na velice dobré úrovni),
* IDE dynamicky zobrazuje počet aktualizovaných řádků DML příkazem,
* cca 3M zdrojových kódů databázového jádra,
* úplná podpora uložených procedur dle standardu (IN OUT parametry, procedury a funkce, volné dotazy (multirecordset), což je hodně praktická vlastnost, která ovšem není zakotvena ve standardu),
* Integrovaný profiler a integrovaný debugger uložených procedur,
* limit pro typ text je 16M.

Mínusy:
* neodladěná instalace v prostředí Linux (a to nepoužívám žádnou exotickou distribuci),
* problémy s kompilací (neodladěnost pro vícero platforem),
* V IDE nelze přerušit prováděný SQL příkaz,
* limit 4G na tabulku,
* neexistence jakékoliv popisu interních procesů, datových struktur, atd vyjma komentářů, kromě oficiální uživatelské příručky neexistují žádné další zdroje,
* při intenzivní zátěži občas nestabilní, nelineární závislost průchodnosti serveru a zátěže, 
* obsahuje komentáře v češtině (mám rád, ale nepatří do o.s. produktu),
* neexistence (utajení) zodpovědných (klíčových) osob v projektu, kritický nedostatek uživatelů - neexistují žádné věrohodné studie použití 602SQL Serveru v praxi (zvlášť při větším zatížení a větších aplikacích)
* starší verze Q.P.  (stejná generace byla v Firebirdu 1.x a MySQL 4.x),
* kromě profileru a tabulky zámků chybí detailnější diagnostika,
* zdrojový kód obsahuje pravděpodobně mrtvý kód (např. parser S-Pascalu, který oficiálně není podporován, stejně tak replikace). U řady modulů byla poslední revize naposledy v roce 1992, tj. zdrojový kód vyžaduje revizi (kterou po svém vzniku prošel jak Firebird  tak PostgreSQL),
* placený fulltext.

Specifika:
* zabudovaný jednoduchý HTTP server umožňující výměnu dat ve formátu XML (placený),
* starší verze podporovali replikaci skrz elektronickou poštu (602 je mistrem v prošlapávání slepých cest - "českých řešení") ,
* spolu s 602SQL Serverem je dodávaný SMTP a POP3 server, který jako úložiště používá SQL server.

Je pro Vás 602SQL Server? a) pokud udržujete produkt, který je na 602SQL Serveru závislý a neplánujete absolutní refaktoring, pak 602SQL Server je to pravé ořechové, b) pokud jste pamětníci a z nostalgie sbíráte artefakty historie IT (doma oprašujete PC Fand), pak (602SQL Server má nepochybně své místo v historii české IT) 602SQL Server musíte mít, c) pokud studujete IT, pak v 602SQL Serveru dostanete balík kódu, který je funkční, a který není tak objemný, jako konkurenční databáze. Docela bych si dovedl představit použití 602SQL Serveru na středních i vysokých školách pro výuku databází (100% jako náhrada MS Accessu). Pokud by si dal někdo práci a pohrál si instalací, pak by možná pár dalších lidí si tento SQL server nainstalovalo a používalo. Určitě 602SQL Server má na to, aby se na něm daly stavět menší aplikace. Ale je tu příliš velké riziko, že jeho vývoj skončí. Otevřený kód alespoň garantuje šanci opravit chyby na které se časem přijde.