Velmi zjednodusene: temporalne constrainty su constrainty pre casove vztahy (medzi zaznamami). ucebnicovy priklad temporalneho constraintu je, ze ty sa nemozes narodit skor ako sa narodil tvoj otec a neskor ako by zomrel (ak zanedbame 9 mesiacov tehotenstva). Vypoved v praci nemozes dostat skor, nez si do nej nastupil, atd.

Temporalna databaza je potom taka databaza, ktora ma k zaznamu priradeny aj interval v ktorom je zaznam platny. Z principu potom ide o databazy verzovane, pretoze pre rozne intervaly mozes mat rozne verzie zaznamu.

Bi-temporalna databaza je potom taka databaza, ktora ma timestampy 2. Nie len interval pre platnost entity, napr. ze ty ako osoba si existoval od svojho narodenia a existujes do svojej smrti. Ale aj interval pre platnost zaznamu (t.j. ze zaznam bol vytvoreny v den, ked ti dali vystavit rodny list, ... a bol platny kym sa v nom nespravila zmena).

Tu sa veci zacinaju celkom zaujimavo komplikovat, pretoze skala vztahov je celkom siroka. Napr. mozes chciet vynutit, aby medzi intervalmi platnosti dvoch po sebe iducich verzii zaznamu pre tu istu entitu bola nulova medzera, ale nie je to vseobecne nutne pravidlo. Naopak nie je ziaduce, aby v jednom case boli platne 2 verzie zaznamu. Ale moze sa stat, ze existuju prekryvajuce sa intervaly existencie dvoch roznych entit, atd.

Fundamenty mas potom na seba navrstvene nasledovne:

Na spodku mas storage engine, u nas to bolo BDB, takze ACID compliant s perspektivou clusteringu.

Nad tym je vrstva pridavajuca podporu pre bi-temporalne zaznamy, constraint recorder (ten je v podstate interne tiez len privatna tabulka v ramci storage enginu) a constraint solver. Volanie constraint solvera je automaticke pomocou callbackov pri CRUD operaciach nad datami.

Nad tym je postavena vrstva implementujuca grafovo/lean-objektovo orientovany pristup k datam. Tu su definovane typove tagy a ich hierarchia (opat ulozene ako privatna tabulka v ramci enginu, potencialne temporalna - takze je mozne verzovat aj typovy system grafovej databazy!), ofarbenia hran (tiez potencialne temporalne) a constrainty pre konstrukciu grafu (opat s podporou temporality, navyse tu aj na urovni definicie constraintu, takze bolo mozne zachytit vztah casu platnosti / existencie zaznamov vo vztahu k hrane).

Uplne na vrchu bol parser SQL-like jazyka, scheduler a sietova vrstva. Jazyk mal "DDL" na typovy system, system ofarbenia hran a temporalne constrainty. "DML" pracoval s timestampovanymi BLOBmi (takze DB nevidela dovnutra zaznamu, ale vedela rozsah platnosti) a mal podporu pre robenie rezov.

Takze vo vysledku bolo mozne nadefinovat typovy system pre data v databaze, system ofarbenia hran a definovat pravidla, ktore umoznovali zachytit temporalitu vztahov.

Co taka temporalna pacmaga dokaze out of box a je celkom zaujimave: Ak sa databazou zacnu robit rezy. Rez je v podstate to, ak sa nebudes pytat na vztahy medzi zaznamami poslednej znamej verzie pre aktualny timestamp, ale bud budes cestovat v case po verziach zaznamov (co si databaza o tomto svete myslela pred rokom?) alebo po realnom case (ako vyzeral svet pred rokom?). Bi-temporalna databaza vie robit rezy v oboch dimenziach naraz. Toto bolo implementovane na vrstve pridavajucej temporalitu, takze z pohladu grafoveho layera to bolo transparentne (e.g. nemal by byt vykonnostny rozdiel medzi dotazom na poslednu znamu verziu 'obrazu' skutocneho sveta a dotaz na nejaky snapshot z minulosti).

Bi-temporalne rezy v relacnych databazach bez podpory temporalnych constraintov casto dost skripu, pretoze nie je velky problem najst "deravy" rez, ale pri grafovych databazach to IMHO funguje lepsie.

V prvejnultej verzii sme myslim nemali aktivne zapnutu podporu verzovania typovych systemov ani constraintov, pretoze sme chceli vediet, ci to vobec poriadne funguje, ale perspektiva na to tam bola (a z hladiska implementacie slo len nastavit storage pre constrainty ako temporalny a pridat podporu do parsera.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.