Re: Discovering new relationships

From: Marshall <marshall.spight_at_gmail.com>
Date: 8 Mar 2007 07:30:27 -0800
Message-ID: <1173367826.938515.302300@30g2000cwc.googlegroups.com>

On Mar 8, 6:18 am, "Walt" <wami..._at_verizon.net> wrote:

> This can be one of the largest issues for "large, shared databases" going
> forward. On the one hand, you want flexibility, so that requirements that
> didn't go into the logical model of prior versions can be accommodated. On
> the other hand you want extreme backward compatibility, so that the
> longevity of the database can be appropriately exploited. The sweet spot on
> the trade-off is difficult to find.

"... so that the longevity of the database can be appropriately exploited"
to me means that existing software continues to work. Software contains embedded assumptions about schema that may become stale, and it would be nice if the software continued to work even if the schema changes. In other words, decouple releases of the schema and releases of the software.

One approach to this problem is simply not to do it. Couple to software and the database and change both at once. This is only practical if you control both the software and the database. It sounds bad when you say it but it's not as bad in practice as it sounds.

The theoretical approach that I usually hear mentioned here is views. I have no direct experience with them so I don't have an opinion on how well they work in practice. But the idea is certainly appealing.

Another approach that I have in mind but that I never hear discussed is to exploit the relational algebra to enable active negotiation of views between software and dbms. There are cases where differences between client software and the dbms's current schema are obvious. I have no idea of the limits of this technique; obviously it can't handle everything because there are changes that are simply incompatible.

It would be interesting to have some data on what kinds of changes were most common. I'd guess "alter table add column" would be in first position.

It would also be interesting to have some theoretical framework for classifying schema changes. Anyone?

Marshall Received on Thu Mar 08 2007 - 09:30:27 CST