Re: Discovering new relationships
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 08 Mar 2007 16:02:12 GMT
Message-ID: <8sWHh.7954$PV3.73095_at_ursa-nb00s0.nbnet.nb.ca>
>
> "... 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?
Date: Thu, 08 Mar 2007 16:02:12 GMT
Message-ID: <8sWHh.7954$PV3.73095_at_ursa-nb00s0.nbnet.nb.ca>
Marshall wrote:
> 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?
I think the time is past due to consider the operations one would find most useful if one habitually dealt with 6NF schemas. Received on Thu Mar 08 2007 - 17:02:12 CET