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 mach - Jo pánové, to byla skutečně revoluce. A nezmíněný aspekt...
-
mach (neregistrovaný)
Jo pánové,
to byla skutečně revoluce. A nezmíněný aspekt - úspora dat na diskovém médiu. Uvědomte si, že se běžně zapisovalo na 8" diskety - kapacita 360KB. (později na 3.5" - tedy kapacita 1.44 MB). A to jste tam museli dostat operační systém + program + data. Konkurence - dBase II - ukecaná a po neočekávaném vypnutí - konzistence dat byla v háji. (tedy nutnost specialisty a reindexace).
Ještě v době SQL jsem hledal, jestli tvůrci nechtějí portovat Fand na Linux. Na ty různé "telefonní seznamy" je to plně postačující. I dneska. Kouzlo uživatelských formulářů a reportů jsem ještě pořád v něčem kompaktním nenašel. -
Uvědomte si, že se běžně zapisovalo na 8" diskety - kapacita 360KB.
Tak já si uvědomuju, že 8" diskety (tj. něco přes 20cm) nebyly v té době u PC ani běžné a ani neměly kapacitu 360 KB. Asi je myšlena 5,25", která měla kapacitu 360 kB později 1200 kB.
https://cs.wikipedia.org/wiki/Disketa#/media/File:Floppy_disk_2009_G1.jpg
https://en.wikipedia.org/wiki/Floppy_disk#Sizes,_performance_and_capacity -
Vláďa fandista (neregistrovaný)
Kupodivu se v diskuzi nikde neobjevila zmínka o poněkud svérázné "odrůdě" počítačů značky Robotron. U těch se diskety 8" (u novějšího typu R1715 byly i 5 1/4" a 3,5") používaly a kromě původního OS a programovacího nástroje výrobcem označovaném jako makro-assembler, nadšenci implementovali OS CP/M a pod ním PC Fand fungoval.
Nezbývá mi než souhlasit s jiným příspěvkem v této diskuzi, že programátor v PC Fandu si těžko zvykal na jiná vývojová prostředí, protože jednoduchost a přímočarost řešení ve Fandu jinde neexistovala
-
falken (neregistrovaný)
rychlá závislost; aboslutní; ... kolem 1991-3 jsem ve FANDu planoval udelat klientske terminaly v nemocnici, pouze takovy rychlejsi frontend (dnes by se reklo mobilni appka/sqlite na rest api), kde terminaly mely ukladat spolecne synchronne do jedne tabulky requesty (ja tomu rikal command) a aplikacni server (delphi 1.0 + interbase; jeste mam doma i krabici) mel vracet kazdemu terminalu do jeho vlastni nesdilene databaze ulozene na sprostem LAN serveru data (messages) na bazi commandu (nic vic, pouze tento pattern, byl rok 1993 a internet jeste nikde ...) - defacto neco jako komplexni rest api response graf. FAND mel deklarativni model s funkcionalnima kalkulovanejma polozkama nad kteryma take automaticky indexoval, pokud mel nadeklarovano - jadro logiky mohlo byt klidne skoro cele v modelech tabulek (F), kde byla take nadeklarovana logika relaci N:1, 1:N atd - sql tam sice nebylo, ale pro zpracovani batch dotazu/updatu se defacto pouzivaly "streamy s eventy", rikalo se tomu "merge" (uz na CP/M kvuli minimalni spotrebe pameti a krmeni hromadou dat z pasek/winchesteru) a tusim az 10 tabulek/streamu mohlo vstupovat podle indexu do procesu s deklarovanymi eventy pri zmenach hodnot, kdy bylo mozne na vystupu generovat nekolik vystupnich temporary tabulek (preddeklarovanych jako modely) a takhle si vytvaret davkove mezivysledky/statistiky/analyzy resp. jejich normalizovane ci denormalizovane podklady - na modelu bylo bezne pouze par polozek fyzicky ulozenych a vetsina polozek "computed" (vcetne linkovani pres relace do ciselniku) - z puvodne 1.NF relacniho modelu dat v tabulkach tak bylo klidne nekdy primo videt do denormalizovaneho pohledu na celou databazi z mnoha ruznych perpektiv, podle toho jaky model byl vychozi - no a nad tim pak byly primitivni flat formulare/views pro eitaci (defacto fakt primitivni templates spis, bez jakekoliv logiky) a sestavy/reporty, coz byla takova kombinace views/templates a merge streamingu s tim ze vstup byl vetsinou 1 denormalizovany stream a vystup pak event based template (detail, head/foot levels by keys...) Typicke programovani (spis skriptovani spousteni generickych ci templated editoru a generatoru sestav pres menu, tot vse) se delo v interpretovanem omezenem pascalu. Ja jsem si tedy tenkrat udelal takovou strukturu projektu pro ty "chytre/stihle" klienty nemocnicniho IS, ze jsem tam v podstate udelal event/state-based "controllery", prave jeden pro kazdy model, s ruznymi views/reports - ... ale na IS uz nedoslo, rozpadal se OUNZ kolem 1993 a bylo najednou na 2 roky prace az nad hlavu se zavadenim mezd a ucetnictvi (VEMA) a skoleni business crowd :-D ... nicmene ovsem ale jeste snad 10 let se tam pak ve FANDa a Paradoxu delal postprocesing uzaverek pojistoven, analyzy, statistiky, etc ... PROČ? simply easy instant changes ... no jak povida pan Klotzer ... defacto dnes ReactJS a par technologii za tim ... (art.sy stack cca? GraphQL, Apollo, ... jo, ted jsem koukal na videa, vcera se vratil ze skoleni... tak neco to bude konecne podobneho mindsetem.... konecne to ti mladaci spichli poradne mozna :-D ... doufam ze tihle nebudou agresivne namachrovane tlacit nejaky rigidni scientologicky procesy a scrumy a kanbany a tak,. ... u facebooku prej je to jinak, the hacker way (tnx Erik) ... well done, ok! :-)
-
Trident (neregistrovaný)
Mliko po brade?
Levna pecka a pecka v dobe predHDDckove se vyznacovala tim ze mela dve 5.25 mechaniky, pozdeji suprdupr hifi 3.5ku. Tj. OS se natahoval z jedne mechaniky a pracovalo se na druhe. V ruznych kombinacich. Fakt neznam nikoho kdo u PC bez hdd pouzival jen jednu disketu.
8 palcovky udajne pro PC existovaly jako externi zarizeni. Jinak bezne byly k videni u vetsich pocitacu a prvnich 8mi bitu. Velmi brzo se preslo na mensi format protoze vyroba 8 palcovych mechanik byla materialove velmi draha vzhledem k nizke ulozne kapacite a diky pokroku v magnetickem zaznamu(male hlavy a magneticka vrstva) to byl i ekonomicky nesmysl. -
JardaA (neregistrovaný)
"Tj. OS se natahoval z jedne mechaniky a pracovalo se na druhe. ... Fakt neznam nikoho kdo u PC bez hdd pouzival jen jednu disketu."
Frajeři nabootovali z diskety, přičemž vytvořili RAM disk a do něj nakopírovali COMMAND.COM, případně plus pár "externích příkazů". Pak vystačili i s jednou disketovou mechanikou; pokud měli dvě, pak pro sebe.
