Re: Search in historical table

From: Lorusso Domenico <domenico(dot)l76(at)gmail(dot)com>
To: Luca Ferrari <fluca1978(at)gmail(dot)com>
Cc: pgsql-it-generale(at)lists(dot)postgresql(dot)org
Subject: Re: Search in historical table
Date: 2023-06-05 14:59:21
Message-ID: CAJMpnG67QfDcCwyubp_yt_E_cHWFu22Uax2Aa7uwp9kbnGdYpg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-it-generale

eheheh grande citazione :-)
duenque esistono due estensioni.
Una gestisce la bitemporalità ma non posso installarla e inoltre sembra
prevedere di chiamare una funzione per ogni insert o update (
https://github.com/scalegenius/pg_bitemporal) l'altra gestisce solo una
temporalità (https://github.com/nearform/temporal_tables) ma potrei
"agevolmente" farla evolvere per includere quello che mi serve.

Ora queste soluzioni usano i timestamp_range, quindi sarebbe ragionevole
pensare che sia la scelta migliore, ma appunto ho qualche dubbio su altri
aspetti come il partizionamento, e in più non mi è chiaro come usare gli
indici Gist con questi oggetti

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

> 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
>

--
Domenico L.

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

In response to

Responses

Browse pgsql-it-generale by date

  From Date Subject
Next Message Luca Ferrari 2023-06-06 06:33:59 Re: Search in historical table
Previous Message Luca Ferrari 2023-06-05 12:56:19 Re: Search in historical table