I currently avoid using these, relying instead on programmed manipulation of
the database using the front end.

I can understand that there are advantages to using both, specifically
automatic maintenance of constraints. I am a bit cautious about slight
mistakes cascading through the entire database and wreaking unpredictable
havoc, however.

Does anyone older and wiser have advice regarding this choice?

John

"John" <?> wrote

Although I am neither, I would love to add my $.02

I abhore enforcement of referential integrity and triggers. Here's why:

I am a programmer. (At least I used to be a programmer before I became a
project manager.) Writing programs, I know what will happen when the code
runs. When I give control over to a DBMS, then I lose the ability to force
events from within the program. In addition, putting triggers and referenial
integrity into the DBMS takes my business objects (rules) and puts them in
the database layer. I prefer to put business rules in the application layer,
where they can be changed. This is the same reason I always use surrogate
keys.

"John" <?> wrote

Triggered actions certainly impose some risk. However, referential integrity
constraints pose no threat. This suggests one should maximize their use of
declarative integrity constraints and minimize their use of triggered
actions.

Of course, one may find times one needs to use a triggered action or two.

"419-Buster" <seeyourlights (AT) hotmail (DOT) com> wrote

In other words, you are ignorant of data management principles and your
ignorance causes you to feel fear.

419-Buster wrote:
Which is exactly why you should do it.

If you have once reached the conclusion that a certain action will result
in inconsistency of data, no amount of programmer wishing should allow that
action to occur.

Keeping the referential integrity in the application layer works well for
the first project. In subsequent projects the programmers may not know
these rules, and code updates that breaks the rules. Result: Inconsistency.

The rules in the database layer may be changed too.

--
Kristian Damm Jensen damm (at) ofir (dot) dk
In C we had to code our own bugs. In C++ we can inherit them.
C gives you enough rope to hang yourself. C++ also gives you the tree
object to tie it to.
With C you can shoot yourself in the leg. With C++ you can reuse the
bullet.

Hi John,

John schrieb:
I don't think to be wise, but I've found some (Euro-)cents for you ;-)

* If you keep the integrity constraints in your application, you have to
fulfill them every time you change rows in the db. Programmers might
forget that and the result would be a loss of data integrity. If you
implement constraints in the database, the programmer must not implement
them with every write access. Code would be smaller and probably easier
to read. Implementation and testing effort is reduced.

* Why not using existing features. Do you want to re-invent /
re-construct the wheel with every new db you design?

* The use of referential integrity constraints is well assisted by case
tools. Referential constraints are shown and documented in your data model.

* Checking the data integrity in the application often causes (depending
on the rule type) to check for existence / non-existence of data in your
db. This data must be transferred from the db server to your client or
to your application server. You have a lot more of transfer volume in
your network. Usable bandwidth will be reduced. In addition, checking
the integrity on the client side would be slower due to network transfer
time.

* The main reason for me to use integrity constraints in the db is:
Every application that accesses your db must use the constraints in the
db. You have a much better control of your data in the db.

--
Mit freundlichen Grüßen / Best regards
Michael Gast
SEPP MED GmbH

All emails sent to this address are never read and never will be
answered. Sorry, but until someone cleans up the spam mess, that's the
way it has to be.

E-Mails, die direkt an diese Adresse geschickt werden, lese und
beantworte ich nicht. Ich bedauere diesen Umstand sehr, kenne derzeit
aber keine bessere Möglichkeit, um die Spam-Flut abzustellen.

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote


But they are not intended to mantain summaries as many people does.


Regards
Alfredo

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

Actually no. I am very well versed in data management principles. I have
only fear for poor code wrtten by sloppy writers of DBMS systems.

On any given day, I may utilize DB2, Oracle, IMS, SQL server, MySQL, and
even - gasp - Access and dBase. Not to mention the odd btrieve system. As
such, over the past twenty years, I have come to trust my judgement more
than that of DBMS writers.

That's what happens when you work in a department supporting 25K users.

"419-Buster" <seeyourlights (AT) hotmail (DOT) com> wrote

Then why do you fear the dbms? Your statements do not seem compatible.

seeyourlights (AT) hotmail (DOT) com says...


This is something like saying "When I don't build the car from scratch
myself, I'm afraid something will go wrong!".


It's so preposterous as to be ludicrous. It's like saying that you could
do a better job of building a car than Mercedes Benz (or even, say, Ford
or Skoda, depending on your RDBMS).


No matter how good a programmer you are, you can bet your bottom dollar
they have thought more about data and its integrity than you have -
either that or you shoud be CTO at Oracle or IBM.


Paul...


--
plinehan y_a_h_o_o and d_o_t com
C++ Builder 5 SP1, Interbase 6.0.1.6 IBX 5.04 W2K Pro
Please do not top-post.

"XML avoids the fundamental question of what we should do,
by focusing entirely on how we should do it."

quote from http://www.metatorial.com