Re: not using foreign keys?

fitzjarrell_at_cox.net wrote:
> On Jun 4, 12:53 pm, spacemar..._at_mailinator.com wrote:

>> i have a question -- is the practice of using FKs to maintain
>> referential integrity an argued (for/against) practice? im now on an
>> enterprise banking project, and the db designer does not use FKs, he
>> feels it creates a "closed system", and prefers to have the coders
>> manage constraints via procs.
>>
>> id never seen this before, but he said its an age-old argument (w/
>> merits) and one he adheres to. is this so, or is it an unusual
>> personal preference?
>>
>> i dont do much of the db work, but im just curious.

> The developers cannot do as well in managing 'constrained' data as the
> Oracle db engine can, period. The read consistency model prevents
> session-level code from 'seeing' uncommitted inserts/updates/deletes
> thus hindering the abilities of any developer to properly 'constrain'
> data.
>
> As far as I'm concerned there are no 'merits' to letting developers
> attempt to 'manage' referential integrity as it only creates a mess
> too convoluted to undo at a later time when the folly of this
> 'decision' is realised.

Agreed. This *should* be a settled argument but people, being people, will persist in doing things the wrong way. One of our developers went to Microsoft dot net training recently, and the trainer recommended not having any constraints in the database because it slows down the development process.

Idiot.

Fortunately, our developer knew better than this and didn't listen to this startlingly bad advice.

Use constraints. Apply them early in the development process (i.e. before you write any code). The best way to prevent messes is to not let bad data get into your db in the first place. Leaving data integrity up to the app is a sure recipe for acquiring bad data.

//Walt Received on Mon Jun 04 2007 - 13:38:28 CDT