I have been in the industry for 12 years now, and worked as a
product developer for Oracle, and have a master degreee
in computer engineering, emphasizing database management systems.
And designed/developed many industrial strength database and application
server systems.
In my opinion , you should never, never, never forgo foreign key
constraints (one exception to this rule is data migration).
This goes for both Relational or Object Oriented DBMS, alike!
I have also worked extensively with J2EE technology, and feel that
this rule is further supported.
Because when it boils right down to it the database is the keeper
of information (the gold repository), and all constraints managing the
database should be maintained within this system. Business logic
is separate! It should be managed in the application server... with
ample exception handling! In the final analisys, you want to ask
your self who do you want to blame for the corrupted data and
reports, and queries that fail due to improper constraints. If you
design/implement your database properly, then corrupted data
is less likely to happen.
Along these lines, I have also never seen a case to support
composite keys in any database, it is a bad idea. Create manufactured
primary keys, and related them to child tables. It is faster at
runtime to join these tables, and if you ever need to change a member
of the composite key, it can be disastrous for 100,000's of records
to change the child fk data.
In short, Kevin has it right - design the database around the requirements
and application server around the business model. Then optimize both
as best you can. If you need to do different analysis of your database
later, like migrate the information into a STAR schema, for data warehouse,
then you can rely on your original RDBMS to be consistent!
Cheers,
Joel A. Thompson
--
--------------------------------------
RHINO Systems Inc.
RDBMS and Internet development
Java/EJB/Oracle systems
http://www.rhinosystemsinc.com
Phone: 530-888-6248 x205
--------------------------------------
Kevin Gaasch wrote:
> I'm going with John on this one. I believe you should seperate the tiers as
> much as possible. Let the DB do what it's best at, let the app server do
> what it's built for. Your application should be oblivious to the type of
> persistence. Let the application manage the business rules. Let the DB
> manage the data constraints. For the kind of hammering your app is giving
> the DB, you need to make sure your DB flavor is scalable enough to manage
> the load. Your application should focus some attention on minimizing
> coupling and communication across tiers. Let the DBA fine tune the hell out
> of the DB, let the architect fine tune the hell out of the application.
>
> Kevin E. Gaasch
> Java Consultant
> Canyon, Texas
> Home: (806)655-2381
> Work: (806)324-4100 x4215
> Cell: (806)674-1523
> email: [EMAIL PROTECTED]
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Wenhui Bai at YSD
> Sent: Thursday, July 26, 2001 7:40 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Foreign Keys, to define or not to define??
>
> IMHO I agree with you to some extent. But it depends on how
> excellent the app server works.
>
> ----- Original Message -----
> From: "Tushar Mangrola" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, July 27, 2001 6:22 AM
> Subject: Re: Foreign Keys, to define or not to define??
>
> IMHO use the database only when the persistency of the object (Entity Bean)
> is required. And the object model should drive the design of the database.
> Putting constraints in the database is totally a different ball game. I
> consider it the old way of doing things. In future I think the RDBMS's are
> going to be replaced by Object Databases.
>
> | -----Original Message-----
> | From: A mailing list for Enterprise JavaBeans development
> | [mailto:[EMAIL PROTECTED]]On Behalf Of John Harby
> | Sent: Wednesday, July 25, 2001 8:42 AM
> | To: [EMAIL PROTECTED]
> | Subject: Re: Foreign Keys, to define or not to define??
> |
> |
> | Ideally, I think the database should be designed according to its
> | own design
> | standards and the object layer should be designed according to whatever
> | methodology you wish to use and a facade should be used as a bridging
> | mechanism between the two. This option of course will probably
> | take the most
> | time to design and implement but then again will yield a loosely coupled
> | architecture that is easily adaptable.
> |
> | As far as implementation of referential integrity in the database is
> | concerned, I can see your point. Many shrinkwrapped enterprise business
> | applications implement referential integrity at the application level for
> | performance reasons although you should be well aware of the cost of doing
> | this. If you have dedicated access to these tables then it may be
> | ok but if
> | other processes are accessing them as well you need to be sure they are
> | implementing the r.i. as well.
> |
> |
> |
> | >From: Sven van �t Veer <[EMAIL PROTECTED]>
> | >Reply-To: Sven van �t Veer <[EMAIL PROTECTED]>
> | >To: [EMAIL PROTECTED]
> | >Subject: Foreign Keys, to define or not to define??
> | >Date: Wed, 25 Jul 2001 12:06:21 -0300
> | >
> | >I�m doing the architecture on a (j2ee) project and I have a disagreement
> | >with one of the analists who is also the DataBase Designer of
> | the project.
> | >First of all, imho, the database design has to follow the UML model for
> | >the application and not the application follow the database model since
> | >my classes might have some other requirements that are not described in
> | >the use cases and because the database design might contain fields I
> | >wont need in my application.
> | >Second, the dba is convinced that the database must contain foreign keys
> | >and constraints. IMHO, the one of the ideas behind J2EE is using each
> | >tier for which it has been designed, as such i think a j2ee application
> | >should not contain any contraints and foreign keys since they might be
> | >very database dependent and would take away part of the portability of
> | >the application and most of all, the application i�m designing has a
> | >shitload of db transactions (20000 inserts 20000 deletes and some 20000
> | >selects every 300 seconds) so constraints and foreign keys really would
> | >screw up my db performance.
> | >
> | >Any opinions ?
> | >
> | >Sven
> |
> |
> | _________________________________________________________________
> | Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> |
> | ==================================================================
> | =========
> | 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".
>
> ===========================================================================
> 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".
