Re: You have my sympathies

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