Re: foundations of relational theory?

On Mon, 27 Oct 2003 18:53:05 -0800, Tony Gravagno <g6q3x9lu53001_at_sneakemail.com.invalid> wrote:

>"Marshall Spight" <mspight_at_dnai.com> wrote:
>
>>"Tony Gravagno" wrote
>>> Also,
>>> relational people want the DBMS to maintain referential integrity,
>>> while Pick people assume that's the responsibility of the app
>>> developer - neither view is "right" in terms long-lasting, quality
>>> solutions, they're just different.
>>
>>There are specific practical benefits to enforcing integrity
>>in the DBMS vs. enforcing them in the various applications.
>>It's not a question of preferences.
>>Marshall
>
>There is no disagreement here. If an order-detail record refers to an
>inventory part then it's critical that the inventory file not be
>purged of referenced parts. This can happen in a poorly coded MV
>application but should not happen with a properly configured
>relational schema. Note the words "can" and "should".

Noted.

But, I would rather say:
...This will happen in a poorly coded MV application but can not happen with a properly configured relational schema.  :)

The only question is weather the following can be true: ...This will happen in a poorly designed relational schema and can not happen with properly coded MV application. ?

I'll assume that it can and move to...

>A relational
>DBA can make the same mistake of improper definition as a MV coder can
>in his app code.

By separating roles of application developer and database designer you are changing the way things are done.

Through higher specialization you achieve better efficiency in any large project.

Also the probability of an error is at best the same given the same level of competence.

If (!) your database designer does a good job you'll have the following consequences:

You might even let developers with less then 20 years of experience to work on your application.

You can change developers in the middle of the project.

You can also give restricted update access to your database to outside parties that you do not control.

You can also have confidence that the next application developer that comes along will not destroy the data.

Since it is declarative and centralized it documents the system and defines its behavior at one place.

And all this without re-inventing the wheel, through standardized features.

Also, most integrity constraints can be more efficiently checked at DBMS level.

In small projects, and I don't mean unimportant or simple - I mean small - which can be done in required amount of time by a team of 3 or less developers, you might not see the benefits of the above approach.

Again the specialized approach applies not only to database development, but to any large engineering job.

At the same time nothing is lost when using this strategy on smaller jobs.

>In both cases the error would be caught and fixed
>immediately.

???

>Granted, the possibility for error is increased if an MV developer has
>multiple entry points into the app for database manipulation.

And this alone is where the discussion stops. You agree that centralized enforcement of integrity constraints is better in one respect and do not provide any deficiencies.

>But a
>properly designed app doesn't have a multitude of entry points for
>maintaining the same data, update routines should be consolidated into
>a manageable number of entry points, and all programs should use the
>same routines. Again we come to the point where proper maintenance of
>the database becomes the responsibility of the application developer
>and his/her understanding of proper design - this is independent of
>the database model.

However the amount of work to check the design is dependent on, not the data model, nor the 'database model', but integrity enforcment strategy.
(has _nothing_ to do with data model, it is a feature of the DBMS)

>Neither model guarantees success, each model is
>subject to the understanding of those who implement it, so I'll
>maintain that neither view is right, but given a proper implementation
>both views are just as valid in this respect - neither view is wrong,
>they're just different and deserve equal understanding.

Integrity constraints (at least key constrains, entity integrity, domain constraints and assertions) could be checked at:

a) application level
b) DBMS level
c) manually by user at input time
d) by auditors
e) by accident :)
f) other (?)

Which do you think has the highest probability of sucesfully maintaining data integrity?

Which one do you think is the most efficient?

Which would you like to see implemented at the hospital your family uses?

Can there be any question to which strategy is better??

P.S. Once again all of this has nothing to do with the data model.

( GoranG79 AT hotmail.com ) Received on Tue Oct 28 2003 - 12:53:54 CET