Re: Data independence

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Thu, 13 May 2004 09:07:03 -0500
Message-ID: <c7vvee$ovf$1_at_news.netins.net>


"x" <x-false_at_yahoo.com> wrote in message news:40a35391_at_post.usenet.com...
> **** Post for FREE via your newsreader at post.usenet.com ****
>
>
> "Alfredo Novoa" <alfredo_at_ncs.es> wrote in message
> news:40a34518.331576_at_news-read3.maxwell.syr.edu...
> > On Thu, 13 May 2004 11:46:22 +0300, "x" <x-false_at_yahoo.com> wrote:
> >
> > >
> > >
> > >
> > >> It is possible to write applications that are independent of
> > >> the change of key constraints in a RDBMS ?
> > >
> > It does not make sense to me.
> >
> Suppose you have an application that use some relvars like this:
> R(A1,A2,A3,A4,B1,B2,B3,...)
> where {A1,A2,A3} is a candidate key for R.
> After some time you find out that {A1,A2,A3,A4} is the "real" candidate
key
> for R.
> Do you need to modify the application ?
> There is a way of writing applications that are not affected by this
change
> ?

This would require changes to any applications in MV, but these changes would likely be quite different from those in a SQL-DBMS. If you abstract it to functions, you are changing the domain of the function and that results in a completely new file in PICK. If the old table is still needed --which might well be the case because it is (don't hit me) a relationship table between A1, A2, and A3 and it is somewhat likely that only some of the fields are now dependent also on A4, right?

I don't think we want to write applications that are immune to such a significant change as this, but we definitely want to try to minimize the risks in making the necessary changes.
--dawn Received on Thu May 13 2004 - 16:07:03 CEST

Original text of this message