The question of DB constraints on EJB maintained code is not just an EJB
thing but rather something that has to be considered in the build of an
application (EJB, CORBA, whatever..).
The obvious pro is that the 'belt and braces' approach gives an extra
level of safety which has come in handy as Robert has pointed out.
The con is, of course, the DBMS overheads and the overhead in maintaining
the constraints. Specifically:
- any insert/update/delete activity may have the overhead of the DBMS
constraint checking (foreign key constraint) depending on whether the row
has RI. The more foreign keys that are changed, the higher the overhead
- in testing and production maintenance, the need to load the tables in the
right order, or disable and re-enable the constraints in the right order if
any data is bulk loaded completely
Personally, having unique constraints is fine but having RI constraints can
reduce the performance of OLTP systems. To a certain degree the fact that
we are modularising the code to maintain objects (and hence rows in the
database) helps us to localise errors. I think that one could use
constraints in the development phase (to check for logic errors) and even
in production (if the transaction rate is not that high). However if
performance drags as a result of the RI , it's the first thing I'd dump..
cheers,
Eddie
At 03:40 23/07/00 -0400, you wrote:
>Robert says:
><<
>Not using a proven mechanism such as database
>constraints to enforce constraints in your model to me would be like not
>wearing your seatbelt because you are afraid of wrinkles in your suite.
> >>
>
>I would say that:
>
>Not using an extraneous mechanism
>such as database inegrity constraints
>in addition to EJB
>to enforce the same thing (relational integrity) second time
>to me would be like
>not wearing two pairs of underwear
>(I think one pair is sufficient).
>
>Plus, the belief that more of the same thing is better calls for having the
>same thing more than twice.
>
>If that's the concept, should one wrap the wrapper, and then wrap it again,
>and again...
>
>I think excess as concept is unnatural.
>
>
>Viktor Gritsenko
>
>----- Original Message -----
>From: Robert Krueger <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Sunday, July 23, 2000 1:22 PM
>Subject: Re: Use DB constraints with EJB's or not?
>
>
> > At 17:11 23.07.00 , you wrote:
> > >Hi,
> > >
> > >I had a discussion with a colleque of mine and we did not reach a
>agreement,
> > >maybe some experts on this mailing list can help us out....
> > >
> > >The question is: Should you use database level constraints to enforce the
> > >integrity of the database or is the integrity of the database the
> > >responsibility of the EJB?
> >
> > Most definitely yes. Not using a proven mechanism such as database
> > constraints to enforce constraints in your model to me would be like not
> > wearing your seatbelt because you are afraid of wrinkles in your suite.
> > Even if you enforce your constraints at the EJB level, why not use the
> > extra safety that database constraints provide. I would view them on the
> > same level as asserts in your code. The only thing I can think of, that
> > would be a con is that you might have some extra maintenance work because
> > if your model constraints change, the db constraints also have to change.
> >
> > from my personal experience I'm completely pro using db constraints as
>they
> > have helped discover numerous bugs in the EJB code in projects I've been
> > involved in. at signal7 we use a homegrown code-generation suite that
> > generates both database definition including constraints and EJB entity
> > bean code including relationships and deployment files from a consistent
> > model so we don't even have the extra maintenance effort. one could
> > argue about using cascading deletes and triggers because they can cause
> > problems with EJB caches but just enforcing constraints in a (relational)
> > database model has helped us considerably in our projects.
> >
> > >My collegues opinion is that it is the responsibility of the EJB to
>enforce
> > >the integrity of the data in the database. If you would implement this in
> > >constraints in the database then both the EJBs and the database would
>have
> > >to know about the integrity rules. Which is duplication of
>knowledge/logic,
> > >which is not a good thing.
> >
> > it depends, see comment above about maintenance and code generation.
> >
> > >At first I agreed with him, but now I have second thoughts:
> > >- What if the database is used by other (non J2EE) applications? The
> > >integrity then must be maintained by the database, or should all
> > >applications be held responsible for the integrity? The latter would mean
> > >distributing the reponsibility over multiple applications, which is not a
> > >good thing? This would advocate to put the responsibility in the database
> > >and define the constraints there.
> > >- By putting the constraints in the database you enforce that their is
>one
> > >place where the data is consistent. Specific application could add
> > >additional constraints for that application into their logic, as long as
>it
> > >does not conflict with the data model.
> > >
> > >I'm anxious to hear your opinions on this....
> > >
> > >Regards,
> > >
> > >Gero Vermaas
> > >
> >
> > regards,
> >
> > robert
> >
> >
> >
> >
> >
> >
> > (-) Robert Kr�ger
> > (-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
> > (-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
> > (-) Tel: 06151 665401, Fax: 06151 665373
> > (-) [EMAIL PROTECTED], www.signal7.de
> >
> >
>===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
