| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>, Adam Brusselback <adambrusselback(at)gmail(dot)com>, Felix Kunde <felix-kunde(at)gmx(dot)de> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: table versioning approach (not auditing) |
| Date: | 2014-10-10 20:44:18 |
| Message-ID: | 54384522.1000208@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 10/7/14, 10:40 PM, Gavin Flower wrote:
>> Yeah, I'm pretty convinced at this point that history/versioning should be built on top of a schema that always contains the current information, if for no other reason than so you always have a PK that points to what's current in addition to your history PKs.
> One of the motivations for having an effective_date, was being able to put changes into the database ahead of time.
Yeah, allowing for future data makes things more interesting. My first inclination is that it's a completely separate requirement, and you would track the history of all records that you had at a point in time. Doing that means you can see things like someone changing the effective date from Nov. 1 to Dec. 1. But clearly this is an area where you have to take the business case into account.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2014-10-10 21:04:46 | Re: Processor usage/tuning question |
| Previous Message | Jim Nasby | 2014-10-10 20:40:03 | Re: How to synchronize tables in remote (production) and local databases in case if the structure of local database's table has been modified |