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

From: Bob Badour <bbadour_at_golden.net>
Date: Mon, 3 Sep 2001 20:15:31 -0400
Message-ID: <v2Vk7.768$LE3.134318184_at_radon.golden.net>


Adrian Veith wrote in message <9mvnqc$rd4$01$1_at_news.t-online.com>...
>From: "Bob Badour" <bbadour_at_golden.net>
>> 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...
>> >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.

Please show me a complex system so complex that it has an integrity constraint one cannot declare with a well-formed-formula.

>Because this is not possible, there are
>things like stored procedures and triggers in a RDBMS.

SQL does not provide adequate support for constraint declaration. There are things like stored procedures and triggers because users do not know what features to demand, and vendors deliver what is expedient for their own immediate interest.

>Historically constraints where one of the first enhancements to various SQL
>dialects.

Really? I seem to recall that most vendors did not even begin to enforce foreign key constraints until the early nineties.

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

The relational model requires that the DBMS enforce declared constraints. While it is impossible to prevent a determined DBA from screwing up the data, properly declared and enforced constraints will prevent the DBA from accidentally doing so. For instance, the DBA cannot add a new stored procedure or domain method that allows users to violate the existing declared integrity constraints.

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

What eqivalent to the relational algebra does OODB provide for constraint declaration? What is the equivalent of a well-formed-formula?

>> >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.

A constraint declaration prevents the idiotic DBA from causing harm with his idiocy.

>> >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?

To prevent an error on one client from affecting other clients.

>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.

Provided that you know all future constraints (and when they will come into existense) when you write your application, it makes sense for applications to only present good data to the dbms.

>Of course nobody gives you a guarantee, that a wrong application violates
>some constraints.

An RDBMS does.

>But who gives you the gurantee, that a wrong application
>issues a DELETE FROM TABLE and omitts the WHERE ID = '007'.

An RDBMS can in some cases.

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

You are safer with declared integrity than you are without it.

Would you likewise suggest that automobile manufacturers should remove seat-belts and passive restraints from all automobiles because nobody can guarantee survival in all possible disasters?

>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).

What check can you not do with a WFF?

>With object
>orientation it is possible to integrate the business logic into the
>database.

It is possible to do with an RDBMS as well. The relational method of declarative logic outperforms the OO method of procedural logic, and very few non-relational odbmses actually integrate any logic into the database.

Most non-relational odbmses rely on application programmes to perform all of the logic.

>And with an P2P OODB you can have this logic at the client-side, where the
>application is running.

Nothing prevents client-side enforcement with a relational dbms.

>> >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 ?

I want full support for relational declarative integrity.

>If so, than you have your answer, that a
>usefull constraint is a programm and not only a declaration.

A well-formed-formula does not issue anything. It simply declares a predicate that the dbms must enforce at all times. It does not specify how the dbms enforces it or when the dbms must take action to enforce it or even that the dbms must evaluate it at any given moment to enforce the predicate. The DBMS might even determine that enforcing another constraint implies it already without further action. Received on Tue Sep 04 2001 - 02:15:31 CEST

Original text of this message