From: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
---|---|
To: | Lorusso Domenico <domenico(dot)l76(at)gmail(dot)com> |
Cc: | pgsql-it-generale(at)lists(dot)postgresql(dot)org |
Subject: | Re: Search in historical table |
Date: | 2023-06-05 12:56:19 |
Message-ID: | CAKoxK+4Ku6qtPfJC87zyfybJKytXq=+h3OWis4T7ekB6X5jJEw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-it-generale |
On Mon, Jun 5, 2023 at 11:35 AM Lorusso Domenico <domenico(dot)l76(at)gmail(dot)com> wrote:
> 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à.
"Marty, tu non pensi quadrimensionalmente" (cit., Ritorno al Futuro 3).
> 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).
Da come lo descrivi, a me viene in mente di usare un range (due valori
timestamp, o meglio _un valore di validità_) e di conseguenza fare le
query con "sovrapposizione" del timestamp voluto nel range. Sempre che
questo sia lo usecase che ti serve.
Ma sono anche abbastanza sicuro che il partizionamento delle tabelle
così diventerà molto complesso,.
Continuo anche a non capire perché ti servono due (tre?) timestamp,
visto che con un timestamp avresti una sorta di linkedlist che
ripercorre la storia di ogni variazione.
Possibile che non ci sia una estensione temporale che ricopra il tuo caso?
Luca
From | Date | Subject | |
---|---|---|---|
Next Message | Lorusso Domenico | 2023-06-05 14:59:21 | Re: Search in historical table |
Previous Message | Lorusso Domenico | 2023-06-05 09:34:26 | Re: Search in historical table |