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
