Re: Store procedure vs Direct statement ???

Sericinus hunter wrote:

Frans Bouma [C# MVP] wrote:
Cor Ligthert [MVP] wrote:

Frans,

I am full expactation waiting on the answer from Bill on this.

(You know that I am in this on your side so I can not do that).

However I think that it is time that this discussion is once well
done.

The sad thing is: there shouldn't be any dispute over what's to be
used. I mean: it's as silly as 'use VB.NET!' 'NO!! Use C#' "No
idiots! Use Java!!!111"....

It is not about that. It is about the fact that very wrong
arguments are so widely spread that people simply take them as axioms
and don't allow even a slightest doubt about it.

True, though in a way I can understand some of those arguments,
because they weren't always false, however today most of them are a
little dated because of the excessive progress made in tooling since
the past decade or so. I mean, years ago, procs were compiled though
today they're not (at least not in most modern databases, if you write
your procs in C or other non-SQL language in DB2, you get a
compilation), for example.

As to what to use, every specific situation will dictate the way
to go. One just need to understand the implications, and discussions
like this are very useful in this respect.

... up till the point when the bitterness enters the conversation and
the discussion becomes nasty.

But I agree with you that it depends on the situation and with the
aspects of the situation you should choose the way you want to work
with data though do it based on reality-checked facts, not myths.

I'm pessimistic about if we'll ever get there. What I wrote in my
other posting about politics is IMHO the core reason why this problem
is still a problem in a lot of organisations. The DBAs are in one part
of the organisation, the developers in another part. There's often a
lot of distrust towards the other group and of course, it's
understandable that if you take away from the DBAs the responsibility
of writing procs and make them 'system administrators', it will make
them angry or at least it would be logical if they get upset.

However that doesn't have to be the case. If the organisations make
the DBA part of the development team, make the DBA the consultant for
the developers what to do best and make them work closely together, it
might be that what you describe perfectly is indeed within reach and
these discussions can be a thing of the past.

A thing that's often forgotten for example is the role of the DBA in
writing functions instead of procs. This is a .NET oriented newsgroup,
so people here work in an OO environment. If the DBA is working
together with the development team (as a real teammember) and writes
functions to do longrunning filters, the functions then can be used by
the developers in O/R mapping scenarios (I use the term o/r mapping,
but any OO <-> db layer will do) and you'll have the best of both
worlds: dataprocessing logic written in the db, and also the flexible
way of working with data in an OO environment with compile time checked
queries etc. etc.

Even though this discussion ended the same as all the other
discussions of the same topic ended: with bitterness and a bad feeling,
I hope the reader now has a good set of options to make a proper
decision.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
.

Relevant Pages

  • Re: Please Help
    ... RDBMS developers hang themselves. ... update-type query cannot violate the RI defined in the database. ... There is often not such a thing as a DBA in the Pick world and when we ...
    (comp.databases.pick)
  • Re: why administrator refuse to give permission on PLUSTRACE
    ... have access to a production database except as an end-user utilizing the ... only happen where the developers know what they are doing, ... I currently support - it isn't typically a mini-app. ... then the DBA won't be the guy who knows the business rules implemented by this ...
    (comp.databases.oracle.server)
  • Re: Developer Permissions -vs- SQL Server Managability
    ... source control and we use those scripts to promote objects to QA and beyond. ... Developers are given access to non-dev boxes only for troubleshooting. ... SQL server that the DBA team manages. ... > - The above would allow dev to create/modify objects and execute/reference ...
    (microsoft.public.sqlserver.security)
  • Re: why administrator refuse to give permission on PLUSTRACE
    ... Management wants the problem figured out and they don't have a DBA ... but they do have very smart developers. ... Puget Sound Oracle Users Group ...
    (comp.databases.oracle.server)
Loading