Dynamism and Database Referential Integrity

[Stefan Schwarzer]

Hello Hung Jung Lu

Hung Jung Lu wrote:
> I say it because I've been involved in a project with a few database
> veterans that, to my surprise, dropped all referential integrity
> requirements: no foreign key constraints. The dynamism achieved is
> that you can version your data much more easily in the complex entity
> relationships: your program can work with versioned data: if a client
> submits old data, you work the old way, if client submits new data,
> you work the new way, and the database tables achieve more longevity,
> because versioning is built-in. New columns can be added...
> relationships can be added/removed in future versions, and the program
> will still work with the old versions, etc. Well, things seem to have
> worked out pretty well.

Sounds interesting. Could you tell more?

> So, could it be that database referential integrity (that is, things
> like foreign key constraints) are there more like a tradition, like
> type-safety idea of the strong-typed languages? Or is it jumping out
> of this paradigm in favor of dynamism too drastic? Has anyone had
> similiar experience/opinion to share?

I think referential integrity constraints are important, at least if
concurrent write accesses on the database occur. Referential integrity
definitions tell the database engine the invariants that have to be
fulfilled during all/concurrent transactions.

Referential constraints are conceptually important for database integrity
in the same sense that semaphores may be important for a multithreaded
application, - depending on that application.

Interestingly, I mean to have read that PostgreSQL uses a kind of
versioning for working with transactions. That might be similar to
what you describe for those database experts, in their case yet more
explicit.

Stefan