Re: You have my sympathies

Amen! Preach it brother.

Signed -

A developer who knows better!

Databases w/out any PKs, FKs or enforced Business rules SUCK!!!

On Tue, 14 Mar 2000, Sybrand Bakker wrote:

>
> James Moore <james_at_banshee.com> wrote in message
> news:Xrtz4.240$m54.2509_at_typhoon2.san.rr.com...
> > "Nuno Souto" <nsouto_at_nsw.bigpond.net.au.nospam> wrote in message
> > news:<38ca3168.3632572_at_news-server>...
> > > Not a PK, a FK or a
> > > stored procedure or trigger in sight...
> >
> > To me, the use of triggers and stored procedures is something to be
 avoided,
> > not sought out. As much as possible should be done by the application.
 The
> > big downside of things like stored procedures and triggers is that they're
> > written in some non-standard extension to SQL. There's no standard way to
> > write database code inside databases; Oracle, Sybase, Microsoft and the
> > others all have their own way of doing things. Instead of using these, do
> > the work in your application instead. People maintaining the code are
 going
> > to be looking at the app anyway, and the more of it that's in one place
 and
> > in a standard language (C++, Perl, whatever) the better. There may be
 times
> > when you can't avoid using some extensions, but think long and hard before
> > you do.
> >
> > - James Moore
> > james_at_MP3.com
> >
> >
> >
>
> This approach is dangerous and stupid, and quite often also results in
> performance hits.
> It is dangerous because it will leave open backdoors. Anyone having access
> to sqlplus (dba's? application administrators?) will be able to do anything
> and potentially create havoc.
> It is also dangerous because the logic most likely will have to be
> maintained in many places (Forms!) instead of one. BTW What kind of standard
> language there is. Is C++ standard? Or is MS Visual C++ standard.
> It is also results in performance hits because enforcing a relationships via
> foreign key will be handled internally by the database kernel. Recent
> experiments in my frim showed this is up to 8 times faster compared to
> enforcing integrity by means of triggers. I do not dare to speak about
> application logic here, are that doesn't reside in the database and needs to
> be invoked separately.
> The experiment was conducted because the application was written in Vision
> Jade.
> As Vision Jade is a multi vendor frontend, it doesn't know about Oracle pk
> and fks. Constraints are implemented partly as triggers, partly as code in
> the Java app.
> Anyone with enough database experience will agree with me this approach was
> a disaster, not only performance wise, also because there was no central
> overview of all constraints and business rules implemented.
> Approaches like your's are exactly the reason why there will be always
> animosity between dba's (who usually think conceptually) and developers (who
> usually just hack away)
>
> Regards,
>
> Sybrand Bakker
>
>
>
>
Received on Tue Mar 14 2000 - 00:00:00 CST