RE: Primary & Foreign key constraints

Well, well, well...

Hi there from a highly unprofessional idiot... :P

Perhaps you would like to tell me why I should enforce RI at the database on all cases? But before you start, go design, build and implement an Oracle data warehoue or data mart.

In general,
I use RI at the database it to ensure that the data rules are consistent. I use RI at the app is to ensure the application specific rules are consistent. And these are not necessarily the same thing.

The data loaded into a data warehouse already conforms to both data and application rules before it's stored.

Personally, to mis-quote you with a few changes,

"There are no merits to this practice. I would say that the person who BUILDS a database WITH FK and PK REGARDLESS is highly unprofessional (an idiot) and has absolutely no idea of RDBMS IMPLEMENTATION. This can lead to current and future problems. "

regards
George :P

> -----Original Message-----
> From: "Abdul Aleem" <abchaudhary-ho_at_beaconhouse.edu.pk>
> [mailto:abchaudhary-ho_at_beaconhouse.edu.pk]
> Sent: Tuesday, May 23, 2000 8:44 AM
> To: smtp_at_inl001@servers["Multiple recipients of list ORACLE-L"
> <ORACLE-L_at_fatcity.com>]
> Subject: RE: Primary & Foreign key constraints
>
>
> To add to what Deepak has said,
>
> There are no merits to this practice. I would say that the person who
> designs a database without FK and PK is highly unprofessional
> (an idiot) and
> has absolutely no idea of RDBMS design. This can lead to
> current and future
> problems.
>
> I would suggest to enforce RI constraints at database level at your
> earliest.
>
> * Heavy Front-end, (more network traffic, client machines
> with good
> specs.)
> * Lengthy code, (difficult in locating problems and making
> modifications)
> * If someone gains access to the database without front-end, can
> insert a lot of garbage without much of a hassle.
> * When you hire new developers they will have to follow the same
> wrong-practice unless someone takes pain and define RI
> (Referential data
> Integrity constraints).
> * If you try to implement RI, be prepared to get a lot of
> duplicate
> records especially in daily transaction tables.
>
> I would appreciate if you could tell what application is that
>
> Hope this helps
>
> Regards,
>
> Aleem
> -----Original Message-----
> From: Thapliyal, Deepak [mailto:DThapliyal_at_ea.com]
> Sent: 23 May, 2000 11:16 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Primary & Foreign key constraints
>
> Rufus,
>
> if you try to enforce RI at the app level .. u
> are looking
> in the face of
> increased IO hits as you try to manually force
> RI rules..
> may also lead to
> funny situations (mutating/constraining) as you start
> playing with triggers
> trying to accomplish the same. thats all my brain cells
> allow me to write at
> this point :-((
>
> deepAk
>
> -----Original Message-----
> Sent: Monday, May 22, 2000 10:44 PM
> To: Multiple recipients of list ORACLE-L
>
>
> Hi Guru's,
>
> Will any one tell, if there is any specific
> advantage if we
> don't have
> primary & foreign key constraints at database
> level. In one
> of our major
> applications I have seen, they do not have primary &
> foreign key
> constraints defined at database level, but
> handled at the
> front end level.
> Can anyone tell what could be the merits if any ?
>
> TIA,
> Rufus.
> --
> Author: Rufus Chinnam
> INET: rufus.chinnam_at_emirates.com
>
> Fat City Network Services -- (858) 538-5051
> FAX: (858)
> 538-5051
> San Diego, California -- Public Internet access /
> Mailing Lists
>
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send
> an E-Mail
> message
> to: ListGuru_at_fatcity.com (note EXACT spelling
> of 'ListGuru')
> and in
> the message BODY, include a line containing:
> UNSUB ORACLE-L
> (or the name of mailing list you want to be
> removed from).
> You may
> also send the HELP command for other information (like
> subscribing).
> --
> Author: Thapliyal, Deepak
> INET: DThapliyal_at_ea.com
>
> Fat City Network Services -- (858) 538-5051
> FAX: (858)
> 538-5051
> San Diego, California -- Public Internet access /
> Mailing Lists
>
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send
> an E-Mail
> message
> to: ListGuru_at_fatcity.com (note EXACT spelling
> of 'ListGuru')
> and in
> the message BODY, include a line containing:
> UNSUB ORACLE-L
> (or the name of mailing list you want to be
> removed from).
> You may
> also send the HELP command for other information (like
> subscribing).
> --
> Author: Abdul Aleem
> INET: abchaudhary-ho_at_beaconhouse.edu.pk
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
Received on Tue May 23 2000 - 04:56:21 CDT