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

Comments follow...

On Mon, 7 Aug 2000 08:03:28 +0200, "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote:

>Yes, definitely 2¢

Thanx for the cheap shot...

>
>Actually, having proper constraints and proper indexes will usually boost
>performance.

I would be very interested in seeing the performance benchmarks that you speak of here...

>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.
While I agree with you for the most part, some designs can and often are marked "concrete" for lack of a better word. These design decisions can be made up front, and will usually result in an increase in performance.

>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.

I guess whoever was in charge of overseeing the people with the permissions but not the experience was not doing their job in the example you speak of.

>Front-end validation can be useful but only in terms of front-end design.
>Constraint validation in a front-end is a big nono.
This is opinion, and there are DEFINATELY cases where front end validation is deemed OK. For example, take a database that services many different types of applications, Different apps have different business rules. I can hear the argument to the above: "If the design is sound, then the constraints should be uniform across apps". But this is not a real world (and IMHO, sound) conclusion.

>The last phrase of your post is IMHO outright offensive. You are implying
>all DBAs are stupid.

I apologize if I came off sounding like this. I was merely stating my experiences with many DBA's I have worked with. Alot of people refuse to look at the big picture, and are so confined to the "standards", that they refuse to think "outside of the box" (jeez I can't believe I said that :)

> 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

Proper training of the developer community in the afore-mentioned areas can drastically reduce the horrendous disasters you speak of. The design of the system rests in the hands of system's architects, DBA'a, and alot of the time -> developers. The database is not always the gatekeeper, or be all, end all, place to enforce such constraints.

>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.
I have, for about 5 years now. I was an ADBA for 3 years. I know that my experience is probably limited compared to yours, but each is entitled to their own opinion. The area that we speak of is wrought with opinions about this, and there are no "once and for all" solution or answer...

Briwn Kresge

>
>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 Tue Aug 08 2000 - 00:00:00 CDT