Re: RI - pros and cons

From: Galen Boyer <galenboyer_at_hotpop.com>
Date: 22 Mar 2002 18:10:01 -0600
Message-ID: <u663oxi23.fsf@grossprofit.com>

On Fri, 22 Mar 2002, dons_at_bimtech.com.au wrote:
>
> "Galen Boyer" <galenboyer_at_hotpop.com> wrote in message
> news:ubsdhayyg.fsf_at_rcn.com...

>> On Fri, 22 Mar 2002, dons_at_bimtech.com.au wrote:
>> > A major drawback of using RI is that it tends to make your
>> > application database vendor specific.
>>
>> How is this?  It is completely transparent to the application.

>
> No it isn't transparent to the app. Databases implement RI with
> differing levels of functionality. What you are saying is that
> you can develop an application and the way the database
> interacts with your app will be the same regardless of the
> brand. At the very least you would need to deal with different
> return codes and errors as in most cases, different databases
> behave quite differently when RI rules are broken.

Ah, yes, you are correct. I was thinking completely along the lines of the RI protecting your data and the app not having to worry about it.

If you want independence, this should be a place where it shouldn't be that difficult, in relative terms, to make it independent by putting a layer that sends your application back a generic code it knows how to handle. You then need to deal with DB specific codes as outliers.

>> > If you intend building apps that will be used by different
>> > brands of databases I'd say putting the RI in your app is a
>> > good thing.
>>
>> Once again.  How is this?

>
>
> Because you can cater for the RI deficiencies in poor
> databases, deal with differences in how the various vendor's
> API return RI errors, handle RI accross brands, etc....

Who died and made the application boss anyways. :-)

>> > Another reason for not using RI is that RI is designed to
>> > stop people who aren't experts from doing stupid things.
>>
>> Wrong.  It is designed to protect the data.  All people of all
>> levels do "stupid" things.

>
> Agreed that programmers do get things wrong but my point was
> that they do however have the opportunity to test things before
> they deploy their code so the applications they build don't do
> stupid things.After testing the application should be stable
> enough not to corrupt the data.

But your application cannot guarantee it, while a DBA can. "Stable enough" isn't stable enough. It has to be completely rock solid, and no DBA is going to believe you when you walk off the street saying your app is fine, don't worry about constraints.

> RI is only really needed because there are so many tools
> available to users that can access the application's data and
> not be governed by an application's business rules .

This should be enough for you, as an application developer, not to even go down this route. Even if you do have completely rock solid RI, a DBA ain't going to trust the next guy, so you, in the end, wasted your time cause all your RI work will be duplicated on the database side, cause the dba says, no way hosey.

> And if you still disagree that RI can't be left up to the
> programmer, who puts the RI constraints on the database in the
> first place ? Isn't there just as much margin for error here ?

No. There are a boatload of tools that are centered around this to make this a rocksolid process. How many tools are written to help you fix your RI issues?

-- 
Galen Boyer

Received on Fri Mar 22 2002 - 18:10:01 CST