cwbe coordinatez:
101
63540
63542
8188908
8317649
8317718
8317728
8317743
8317791
8317906

ABSOLUT
KYBERIA
permissions
you: r,
system: public
net: yes

neurons

stats|by_visit|by_K
source
tiamat
K|my_K|given_K
last
commanders
polls

total descendants::1
total children::1
show[ 2 | 3] flat
haluz, ja osobne by som to vrstvenie robil uplne opacne, db engine by obsahoval vsetky zname data a logika temporality by bola v aplikacnej casti na urovni kodu.
tj, vzdy by sa robila vseobecna query na zobratie subgrafu (aj so vsetkymi verziami entity) a az priamo v kode aplikacie by sa filtrovalo na temporalitu ci bi-temporalitu.




0000010100063540000635420818890808317649083177180831772808317743083177910831790608318044
ventYl
 ventYl      21.03.2017 - 12:21:32 , level: 1, UP   NEW
tym ti ale typicky v case rastie objem dat, ktore bude aplikacia na rovnaku kveru dostavat proporcionalne s tym, aky bude traffic na databaze.

plus poziadavka na vytiahnutie vsetkych multiverzii rovnakeho zaznamu v domene transakcneho casu nie je uplne typicky workflow. v domene realneho casu je to workflow pomerne zriedkavy a grafove operacie sa nad tym dost dobre robit nedaju, pretoze integrita skrz verzie zaznamu nie je garantovana.

ale ano, existuju riesenia pre podporu temporaliy (zvacsa v relacnych databazach), ktore funguju podobnym sposobom.

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