Riesenie problemu prechodov medzi stavmi mi pride jednoduchsie najma v normalizovanej DB strukture.
Aktualna DB struktura skoro 1:1 zodpoveda API endpointom a strukture elementov v nich, hoci napr na tabulkach ‘projekty_vrealizacii_intenzity_zdroje’ resp ‘projekty_ukoncene_intenzity_zdroje’ vidno, ze aspon rozne zdroje ako listove elementy intenzit na projektoch ma @Ernest_Walzel uz teraz pekne spracovane ako jednotlive instancie v tychto tabulkach.
Verim ze obdobne by sa dalo riesit aj projekty ci ZoP v roznych endpointoch (ano je to kus prace), ktore ako consumer dat v SQL nasledne potrebujem pre projekty pracne Union-ovat a pre ZoP zase Case-ovat.
Iste, normalizacia nemusi byt nutne sucastou samotneho zberu dat, ale velmi sa hodi pre ich dalsie spracovanie. V tejto situacii by mozno stalo za to zadefinovat nad aktualnymi datami aspon akesi normalizovane Views nad ktorymi by sa nasledne dalo jednoduchsie selectovat (aby napr. tie uniony nemuseli byt rozkopirovane v mnozstve podobnych selectov). Ak by s takymito Views vedel Metabase pracovat ako s beznymi tabulkami, urcite by to zjednodusilo aj pracu v jeho vyklikavacej casti.
Nasledne by to mohlo zjednodusit aj zatial chybajucu dokumentaciu k tejto scheme v ramci https://ekosystem.slovensko.digital/otvorene-data kedze v aktualnom mnozstve tabuliek nie je vobec jednoduche sa zorientovat.
Moj ‘normalizovany’ pohlad napr. len vo vyseku struktury pre cerpanie na projektoch redukuje 24 vasich tabuliek (u mna itms_typ) na 6:
