Vlákno názorů k článku PC FAND: historie slavné české databáze z 90. let, která nepřežila nástup SQL od Josef Markvart - Článek je docela rozsáhlý, ovšem některá tvrzení mi...
-
Josef Markvart (neregistrovaný)
Článek je docela rozsáhlý, ovšem některá tvrzení mi přijdou sporná. Např. že PC FAND nepřežil nástup SQL databází. Nevím jestli pro FAND byl SQL nějaká konkurence - tak to asi nebylo nikdy chápáno , FAND byl spíše doplněk k velkým systémům. Že je občas trochu přerostl je již jiná věc. Navíc i dnes, v roce 2018 ty aplikace stále žijí a existují opravy některých starých omezení FANDu, kdy se omezení na rok 2020 prodlužuje na rok 2030, 2050 . . . .
A dále např. . .. SQL (PC FAND je jím nedotčený). No tomu moc nerozumím, FAND je postavený na stejném relačním DB modelu jako SQL, má analogické datové typy a některé další vlastnosti, kupříkladu implicitní hodnoty, integritní omezení, vypočtené hodnoty.... Konec konců byl ve vývoji i SQL - FAND, client pro SQL databáze. Ten vývoj skončil spíše na tom, že byl drahý - otázka obchodního modelu. Ale technicky pro aplikaci FANDu bylo jedno jestli má tabulku vlastní nebo je na SQL serveru. Což něco napovídá o příbuznosti datového modelu FANDu a SQL. ALIS by asi ještě dnes mohl najít originál příručku SQL FAND. Obávám se, že FAND je mnohem méně smrtelný než mnoho programátorů co v něm programovali. -
Pokud bych bral FoxPro, Dbase, MS Access jako konkurenci PC FANDu v kategorii souborových databází, tak koncem 80 let - případně v první polovině 90 let implementovali SQL - coby další interface pro přístup k datům. O ničem podobném integrovaném do PC FANDu nevím - a o SQL - FANDu jsem netušil - o tom se mi pan Klötzer nezmínil (a jelikož se to ven asi nedostalo, tak z jiného zdroje to ani nemohu vědět). Naopak, co mne zarazilo, tak byl integrovaný PROLOG - což je v této kategorii docela netypická vlastnost.
SQL beru jako dotazovací jazyk - a ten v PC FANDu není, nebyl (a nevidím v tom vůbec žádný problém). O relačním modelu (který používá drtivá většina SQL databází i PC FAND) vůbec nediskutuji - to je naprosto jasné - a zmínil jsem, že PC FAND byl v tomto ohledu moderní a vycházel z relačního modelu.
SQL FAND si docela dobře dovedu představit - zrovna tak si dovedu představit PC FAND, kde by storage zajišťovala SQLite.
Zrovna tak nezpochybňuji, že se PC FAND používá - používá se, a používá se hodně. Na druhou stranu poslední oficiální build je z roku 1999 a žádná další verze se neobjevila. Jestli se to dá označit jako konec nějakého produktu nebo ne, to je samozřejmě subjektivní a i vágní - žádný sw neumírá - jen se přestává rozvíjet, modernizovat nebo portovat. A teď to bude pomalu určitě 30 let, co se PC FAND používá (spíš více) a skoro 20 let od poslední aktualizace (a stále se používá). To už něco znamená. -
Josef Markvart (neregistrovaný)
(býval hotline FANDu v ALISu) Již si nepamatuju detaily z SQL FANDu, ale myslím že tam byl nějaký komunikační server, který překládal FANDovské příkazy do jazyka SQL. V úloze FANDu - zdrojáku - stačilo označit určité tabulky příznakem .SQL (podobně jako indexové soubory .X) a s nějakými omezeními byly tyto tabulky místo dat. souborů FANDu uloženy na SQL serveru. Implementace komunikačního serveru byla tuším pro Informix. Byl k tomu i spec. překlad FANDu - vlastně z důvodů úspory paměti u standardních variant runtime. Komunikační server psal stejný autor jako ODBC driver, Tom Havelka. Dnes již pan důchodce stejně jako G.K. Bylo tam uděláno spousta práce ale na dotažení technické i obchodní by byly zřejmě potřeba kapacity které ALIS neměl, resp. měl další oblasti činnosti které dostaly prioritu.
-
qqq (neregistrovaný)
Informix,
Na tom byla uložena data IS DIAMAC :-)No chtěli jsme DIAMAC, ale peníze nebyly.
Koupili jsme DEC server s Unixem a Informixem a koketovali jsme s převodem námi napsaného IS ve FANDu na tento server. Právě dle výše popsaného...Nakonec peníze byly a přešli jsme na DIAMAC (taky TUI, zprvu uživatelsky nepříjemné, ale uživatelé si zvykli a IS jsme běhěm asi tří let kompletně rozjeli). A stejně jako FAND bylo TUI DIAMACu schopné pracovat na i tehdy úplných šrotech 286...
-
backup (neregistrovaný)
....FAND je postavený na stejném relačním DB modelu jako SQL ...
ta veta je nejaka divna nebo ji nerozumim.
SQL je dotazovaci jazyk pomoci ktereho lze vytahnout data z jakehokoliv systemu - i takoveho, kde vyvojar nemel o relacnim modelu nejmensi potuchy. Je potreba pouze napsat ten spravny driver (parser, provadeci program). To, ze se pouzije SQL jeste tedy neznamena, ze nejaky system je relacni.
.... má analogické datové typy a některé další vlastnosti, kupříkladu implicitní hodnoty, integritní omezení, vypočtené hodnoty....
Tyto vlastnosti maji vsechny databazove systemy, hierarchicke i sittove. To by take neprokazovalo pritomnost relacniho systemu.
Co je tedy nejaky relacni sytem. Takovy, kde je zakladem tabulka. Ale v uzivatelske prirucce FANDu je rec pouze o souborech. Slovo tabulka ve smyslu SQL se vyskytuje pouze jednou. '*.SQL -- soubor urceny k emulaci tabulky SQL servru diskovym souborem'.
Rekl bych, ze formulace pana Stehuleho (nedotcen SQL) neni naprosto spravna. Vyvojari se podle mne skutecne v posledni chvili snazili naroubovat na souborovy system FANDU SQL pristup. ODBC driver je takova klasika, kazda ISAM-databaze ma takovy, aby se k tem souborovym datum dalo pristoupit pres SQL.
Ale take to zaroven vlastne potvrzuje tvrzeni pana Stehuleho, neb vyvojari sami videli absenci SQL jako nedostatek.
