Administrace komentářů

ono je to takhle. Ten system, pro ktery se snazim verifikovat tu pgsql je firemni informacni system ve kterem pracuji neustale na pozadi desitky programu, ktere neustale zjistuji stavy na skladech, aktuani dodavky, postupy prace, stav vyroby a neustale optimalizuji vyrobu a objednavky. Mezitim pracuji (pres den) samozrejme interaktivne uzivatele. Napr. tabulky vyrobnich zakazek jsou jaksi neustale 'pod tlakem', nebot se podle toho, co si prave mysli simulace rozkladaji na subzakazky, meni se jejich cas a jednotlive vyrobni prikazy meni svuj stroj, cas naplanovani, mnozstvi a pod.

Neco takoveho nelze samozrejme programovat jako obvykle projekty pro banku, kde si sednou desitky programatoru na 2 roky do kamrliku a potej s kazdym sql-statementem a kdyz si nevedi rady, tak vydaj hlasku, ze si ma neco nastartovat uzivatel znova. Tady se na to slo s frameworkem, ktery generuje ty sql-statements sam na zaklade vlastniho jazyka a aby byl ten system menitelny, je to cele rozdeleno do mnozstvi minimodulu, ktere nejaky generator sesumiruje dohromady.

Aplikacni programator tedy nejake SELECTy vubec nevidi, ty zna jen ten generator a proto si nemuze nad kazdou libovolnou kombinaci tech modulu zamyslet, co udelat, kdyz ta transakce nahodou nevyjde. To musi udelat ten system sam. Programm je z poloviny 90 tych let s nejakou zvlastni databazi od Siemense. Ta databaze (nebo ten framework , to nevim) si vede vlastni checkpointy a a dokaze transakce opakovat ze se to rozbehne od toho checkpointu znova. Bylo mi receno, ze je to neco podobneho jako ta slavna NonstopSQL od firmy tandem.

No a ja se snazim nyni tak trochu osahat pudu , zda by se nedala nejaka rychla rekneme 'uprimne' levna databaze k tomu pouzit. Proto jsem tak trochu naslepu vypalil a doufal, ze se nekdo s nejakou takovou problematikou uz setkal - nahoda je vul