Here's my 2cents.
I always like to keep my structiral integrity as close to my data as
possible, that's one of the attractions of Objects. Putting structural
integrity into the database means I'm somewhat protected from access by
other tools or programs. That means I can have legacy bits like a reporting
tool that updates some flags in the db without having to raft some C code,
COM->CORBA bridge, EJB wrap on my CORBA to keep that all working.
To put it another way ... if you asked someone to enter in their email
address into you website, as a mandatory field, where would you check it?
At the client end, in the view bean, in the business logic, in the database?
One trend that I have noticed though is that corporate/in-house developers
will almost always use database constraints. Many package vendors use no
database constraints (like most Financials, which then requires lots of
extra work).
Thor HW
----- Original Message -----
From: "Victor Langelo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 24, 2000 7:09 AM
Subject: Re: Use DB constraints with EJB's or not?
> In theory it would be nice to enforce integrity constraints in only one
place.
> In practice, you'll probably have to compromise. Here are the reasons we
had to
> implement a hybrid solution.
>
> 1) Some integrity checks are much faster if implemented in the DBMS. For
> instance, unique constraints would require an extra DB statement execution
if
> implemented in EJB instead of DBMS.
>
> 2) There is no standard exception (at least in practice) thrown by
different
> JDBC drivers and DBMSs for the same type of constraint. If you need to
write
> beans that support multiple drivers/DBMSs then you're going to end up with
a lot
> of messy code to in order to report an understandable error to the user.
>
> 3) Some DBMS cannot handle complex foreign key constraints. For instance,
we
> have some dependent objects (email & phone numbers) that can be attached
to
> various tables. This occurs because we chose to map various subclasses of
people
> and organizations to different tables. Stored procedures or triggers are
> required for the logic needed to implement referential integrity for this
case
> in the DBMS. It much easier to implement this kind of constraint in the
Entity
> beans.
>
> My two cents,
>
> Victor Langelo
>
>
> Gero Vermaas 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?
> >
> > 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.
> >
> > 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
> >
> >
===========================================================================
> > 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".
