Re: Search in historical table

Ciao Luca,
perché sono p***a, volevo mandarla a quella generale in inglese. :-)

Rispondo alle tue altre domande.
No un unico timestamp non è sufficiente, mi servono i periodi di validità,
in accordo con l'approccio bitemporale. In realtà mi sto chiedendo se non
debba gestire la tri-temporalità.

Ad ogni modo dopo aver memorizzato i dati, uno usecase che DEVO garantire è
una estrazione che rigeneri tutti i passaggi di un dato elemento, cioè
tutte le versioni valide in un certo spazio temporale (bidemensionale) X
che è input utente.

Ogni record è valida da una momento ad un altro dal punto di vista utente,
e da un momento ad un altro dal punto di vista del db.
Immagina di dover registrare lo stipendio dei dipendenti (rossi dal 01/05
prende 100, prima prendeva 95).
Lo stipendio può essere inserito prima o (per dimenticanza) dopo il momento
cui bisogna dare i soldi al dipendente. Il tempo utente conterrà comunque
dal 01/05 - sinedie
Il tempo db conterrà dal momento vero di variazione - sinedie.
I dati storici si adegueranno di conseguenza.

Le misure non le ho fatto su postgresql ma le conosco su altro dbms e
parlando di miliardi di record non sono un granché, soprattutto nelle
ricerche temporali.

Ho iniziato a guardare Gist, ma devo dire che non ci ho capito tantissimo.

Il giorno lun 5 giu 2023 alle ore 08:30 Luca Ferrari <fluca1978(at)gmail(dot)com>
ha scritto:

> On Mon, Jun 5, 2023 at 2:12 AM Lorusso Domenico <domenico(dot)l76(at)gmail(dot)com>
> wrote:
> > Question 1:
> > Which is the right approach? use 2 timestamp range fileds (one for "user
> time" and the other for "db time") or 4 timestamp fields (a couple for each
> dimension)?
> >
>
> I don't think there is a right approach, rather it depends on which
> granularity you need. As you described, I suspect one timestamp for
> every fact will suffice, assuming the last timestamp is also the valid
> record.
> If you are going to store a validity in terms of "since now to then",
> a range could be your friend.
>
> > Question 2:
> > How to create an index that allows query to extract records contained
> (also partially contained) in a period?
> > I mean: give me each record valid from user point of view between
> 2023-01-01 and 2023-03-15 AND valid from db point of view between
> 2023-02-01 and 2023-05-15
>
> What's wrong with something like "WHERE ts >= '2023-01-01' and ts <=
> '2023-03-05' ? Are you scared about performances (that you probably
> haven't measured yet)?
> It could also be a good idea to start with a partitioning on the
> timestamp if you expect to store a lot of records.
> Or even better, use a timescale like extension.
>
> Question 3: why english on an italian mailing list?
>
> Luca
>

--
Domenico L.

per stupire mezz'ora basta un libro di storia,
io cercai di imparare la Treccani a memoria... [F.d.A.]