Re: No foreign keys??? What the???

Yes, definitely 2¢

Actually, having proper constraints and proper indexes will usually boost performance.
Also what you propose if validating data *outside* the database. I'm right now working on a project to get the validation *in* as validation outside the database has proven to be way more *in*efficient. Also, you would usually make sure for *any* front-end tool the database is a black box, and front-end manipulations are not going to make it invalid. Finally, I have seen an example of such "stringent" rules. That usually resulted in someone who entered the garbage, not being capable of deleting it. You could imagine what happened: the garbage just stayed where it was.
Front-end validation can be useful but only in terms of front-end design. Constraint validation in a front-end is a big nono. The last phrase of your post is IMHO outright offensive. You are implying all DBAs are stupid. With the current firm distinction between developers and DBAs and developers usually not working with DBAs because they, as you do, look down on them, this usually results in applications which are in DBAs eyes outright disasters: offensive SQL statement no constraint validation
etc etc
You'd better work together with DBAs, or stay in your own area, and don't have a verdict in an area where your experience is definitely too limited.

Regards,

Sybrand Bakker, Oracle DBA

"Brian Kresge" <bkresge_at_rochester.rr.com> wrote in message news:q1hsos8v64kqf425i7m74jc85jambs0ftj_at_4ax.com...
> I feel the need to put my 2¢ in here... I am a developer aspiring to
> be a DBA. Although I would agree that integrity checks in the
> database are the right path 98% of the time; there are situations
> where it is prudent to disable integrity checks in the database.
>
> Case in point, an application that utilitized over the web, and is
> maintained "in-house". The application is the only avenue through
> which users may update the data. If stringent rules are defined
> within the organization to not manually update the database (unless
> "qualified"), this can increase performance considerably for the end
> user.
>
> Take for example, a table that has a lot of code fields in it.
> Thorough analysis would state that all code fields would map to their
> respective lookup tables. But if the application controls what the
> valid values are that are inserted into these respective fields, there
> is minimal (if NONE) performance hit. Of course, othere examples are
> out there, careful analysis is needed to discover them.
>
> IMHO, the typical DBA all too often jumps to conclusions where
> detailed analysis may provide a much better answer.
>
> Only my 2¢ :)
>
> Brian Kresge
> SW Engineer (for now)
>
>
>
> On Mon, 03 Jul 2000 05:23:33 GMT, Greg Stark <greg-spare-1_at_mit.edu>
> wrote:
>
> >
> >"Sybrand Bakker" <postbus_at_sybrandb.demon.nl> writes:
> >
> >> Yes, this is crazy!
> >
> >You guys have both happily answered a question with far too little
> >information. Too often people are happy to apply the same old stock
 answers to
> >questions without thinking about if the canned solution is really
 appropriate
> >to the problem at hand.
> >
> >In an application with an application layer interface through which all
> >queries proceed most referential integrity constraints are superfluous.
 In
> >some cases they're still useful as a safeguard against buggy code,
 however in
> >cases where they are performance critical the extra index lookups would
 be
> >pointless and costly.
> >
> >In other cases the integrity constraints are subtle. I find the best way
 to
> >control data integrity is at the application level where the data
> >representation is actually being manipulated and the more important
 subtle
> >checks can be performed as assertions within the code. Rather than at the
> >database level where only a crude understanding of the data being
 represented
> >is available.
>
Received on Mon Aug 07 2000 - 00:00:00 CDT