Re: Dreaming About Redesigning SQL
Date: Thu, 23 Oct 2003 08:58:20 GMT
Message-ID: <MKMlb.2605$ao4.8381_at_attbi_s51>
"Dawn M. Wolthuis" <dwolt_at_iserv.net> wrote in message news:6db906b2.0310200923.63c18da_at_posting.google.com...
>
> The downside of this is that if you have another language or
> application that wants to use the same data persistence, then it
> either should make use of the typing/constraints established for the
> applications that use that data, or it must re-encode those
> constraints in the language of the application.
Neither of those choices appeals. I think your solution is worse than the problem!
> Unfortunately, such protection often ends up to be the problem for
> agility -- just because we thought phone numbers were necessarily
> associated with a location doesn't mean they always will be, for
> example.
So you change the schema. If your constraints are stored centrally, then you change them in one location. If they are encoded into applications, then you have to change them in every application. Central control of constraints is a clear winner in this scenario.
> Also, if a developer is not permitted to change these
> constraints, but must wait for such changes from others, that can hold
> things up quite a bit.
This is a fair criticism. But this is just the cost of centralization. How is the situation any better when the constraints exist in every application? Then, we get into a situation where half of the applications have been updated and half haven't. Sure, some folks got out the gate faster, but now half of the apps are causing corruption.
Marshall Received on Thu Oct 23 2003 - 10:58:20 CEST