Re: Clean Object Class Design -- What is it?

From: "Bob Badour" <bbadour_at_golden.net> Newsgroups: comp.databases,comp.databases.object,comp.databases.theory Sent: Sunday, September 02, 2001 4:52 AM Subject: Re: Clean Object Class Design -- What is it?

>
> Adrian Veith wrote in message <9mqjbh$dl9$02$1_at_news.t-online.com>...
> >"Bob Badour" <bbadour_at_golden.net> schrieb im Newsbeitrag
> >news:6QTj7.601$Ny1.123682876_at_radon.golden.net...
> >>
> >> I disagree that constraint declaration is programming. The ISO standard
> >> vocabulary requires a program to have both declarations and
instructions
> >to
> >> satisfy some particular task. A constraint declaration is not a program
> >any
> >> more than a conceptual analysis is a program.
> >
> >To make a distinction between a declaration and short method is quite
> >needless.
>
> I disagree. They are fundamentally different, and one can easily declare
> constraints that no short method could enforce.
>
> >> I understand that ODBMSes require one to program in order to enforce
> >> integrity because they generally treat integrity enforcement as nothing
> >more
> >> than a sub-task in every other task (or method, if you prefer).
> >
> >I can see no reason, why a OODB should not have constraint declarations.
>
> Relations and the relational algebra provide a very powerful means for
> constraint declaration. What does OODB have to offer in comparison?
>
>
> >But the point is, if this is usefull ?
>
> Of course, it is. Otherwise, how does the DBMS prevent a DBA from screwing
> up the data by mistake? Or do you only hire infallible DBAs?

Please, show me a complex system, where it is enough to define some *easy* constraints to ensure integrity. Because this is not possible, there are things like stored procedures and triggers in a RDBMS. Historically constraints where one of the first enhancements to various SQL dialects.

The problem is, that it is not enough to define constraints, therefore your DBA can mess up your data with or without constraints.

The system of constraints could be easily adopted within an OODB. But I doubt, that it brings you any further.

> >The advantage of checking constraints in a method is, that the checking
can
> >be done at the client side.
>
> Nothing prevents client-side enforcement of declared constraints, which
> makes this a non-advantage.
>
> Method-based constraints do not prevent a DBA from writing a new method
that
> violates the existing known integrity rules.

Nothing prevents an idiotic DBA from being an idiotic DBA.

> >Checking constraints at the server side is not
> >that effective and in general limited.
>
> This is an extraordinary statement that contradicts considerable empirical
> evidence. On what do you base the statement?

If a programm at the client-side initiates the change of data, why should it be effective to check the data on the server-side? Anybody will agree, that it makes no sence, to initiate a change of some hundred records only to get the server response, that you have violated a constraint. Therefore, if you programm an application, you will perform all the checks before you post your data.

Of course nobody gives you a guarantee, that a wrong application violates some constraints. But who gives you the gurantee, that a wrong application issues a DELETE FROM TABLE and omitts the WHERE ID = '007'.

The problem of a wrong application, is the same, as the problem of an idiotic DBA. You are never save.

Therefore my opinion, that is better to have a system, that enables you to do ANY check you need (methods come quite close to this). With object orientation it is possible to integrate the business logic into the database.
And with an P2P OODB you can have this logic at the client-side, where the application is running.

>
>
> >If you define integrity, that a certain value is inside a given range,
than
> >the concept of constraint declarations is enough.
>
> This barely scratches the surface of constraint declaration.
>

Are you talking about a simple constraint declaration. Or do you want a constraint to issue a query ? If so, than you have your answer, that a usefull constraint is a programm and not only a declaration.

>
> >But if things are getting
> >more complex this concept fails. (SQL fails!).
>
> Of course, SQL fails. SQL utterly failed to provide relational constraint
> declaration just as it failed to deliver most of the relational model.
>
>

Here we agree totaly :-)

Adrian Veith. Received on Mon Sep 03 2001 - 13:05:06 CEST