Re: Database design: Temporal databases

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: David <wizzardx(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Database design: Temporal databases
Date: 2008-06-18 21:36:42
Message-ID: 1213825002.29769.8.camel@dogma.ljc.laika.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 2008-06-18 at 14:05 +0200, David wrote:
> How well do temporal databases work? Do RDBMS (ie Postgresql) need
> add-ons to make it effective, or can you just add extra temporal
> columns to all your tables and add them to your app queries? Does this
> increase app complexity and increase server load a lot?

I think PostgreSQL provides the best tools for this, although I'd like
to make them even better.

As Richard pointed out, I have implemented a "period" data type here:
http://pgfoundry.org/projects/temporal

The things that need to be added, in my opinion, are:

(1) Temporal keys, that is, an index that can implement a non-
overlapping constraint. Right now we only support the UNIQUE constraint,
but non-overlapping is necessary for real temporal keys using a period
data type.

(2) Temporal foreign keys

(3) Temporal joins

I am going to make an attempt to accomplish #1, but I am still in the
planning stages.

As for application complexity, the fact that PostgreSQL keeps historical
data should be transparent to the application entirely, unless that
applications cares to look at the historical data.

I am trying to make performance reasonable by providing the period data
type (which is indexable).

Regards,
Jeff Davis

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Stuart Luppescu 2008-06-18 21:41:07 Dump and restore problem
Previous Message Tom Lane 2008-06-18 21:25:37 Re: migrating from mysql: need to convert empty string to null