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