Re: Search in historical table

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

In response to

Responses

Browse pgsql-it-generale by date

  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