There is also the issue of testing and how expensive it is to fix data
that is not referentially entact. If the dbms won't let you do
something that does not make sense from a data model point of view then
a large project with many programmers will find these bugs faster and
the programming effort is less because the dbms creates the foriegn
keys.
I worked on a project where the dba hated foriegn keys and wrote
triggers for all the inserts, deletes and updates so the code did not
have to change in a jillion places whenever the data model changed.
Worked pretty well from a project management stance but portability went
out the window when they had to scale to a different database and had to
rewrite all the triggers for something else other than sqlAnywhere.
Most commercial dbms packages now support java as a trigger language I
understand but I am not sure what that does to performance.
I would guess a large part or the equation is where is the application
code running as opposed to the dbms. How fast are the machines, and how
big and fast is the network pipe to them. If an application has to
make three or four calls to the database to perform referential
integrity checking for each create update and delete then network
latency becomes an issue as well. Relationships with cascade deletes
are a good thing in a situation like that.
My two cents.
Bret Hughes
Ian Alexander wrote:
>
> Actually, you *do* need them if the need is to conform to a standard of
> some sort that requires foreign keys. I've worked for a few places where
> this was the case. Granted the spec could be changed, but most times you
> won't have that option.
>
> ###############################
> Ian J. Alexander <[EMAIL PROTECTED]>
> Senior Software Engineer
> EazeNet
> 817-557-3038
> ###############################
>
> On Mon, 17 Jan 2000, Jason Costomiris wrote:
>
> > On Mon, Jan 17, 2000 at 10:32:32AM -0600, Alan Mead wrote:
> > : If COMMIT and ROLLBACK are important or
> > : you need "true" foreign keys, then you probably need postgresql (I think
> > : there are workarounds on the mysql website).
> >
> >
> > You're correct with respect to support for transactions..
> >
> > However, don't kid yourself.. Nobody *needs* foreign keys.. If your
> > code manages its data properly, you'll never need 'em. :)
> >
> > --
> > Jason Costomiris <><
> > Technologist, cryptogeek, human.
> > jcostom {at} jasons {dot} org | http://www.jasons.org/
> >
> >
> > --
> > To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
> > as the Subject.
> >
> >
>
> --
> To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
> as the Subject.
begin:vcard
n:Hughes;Bret
tel;fax:918.587.0131
tel;work:918.587.0131
x-mozilla-html:FALSE
url:www.elevating.com
org:Elevating Communications Inc
adr:;;PO Box 1323;Tulsa;OK;74101-1323;USA
version:2.1
email;internet:[EMAIL PROTECTED]
title:Chief Solutionist/President
x-mozilla-cpt:;19888
fn:Bret Hughes
end:vcard
