Sql / Dot Net General Discussion

Hi,

I wanted to start a general discussion more for getting some thoughts
on what other people think/practice out there just to see how far (if
at all) I'm off base on my own thoughts.

My primary experience is developing applications using VB or DotNet. I
have some sql skills but they are limited. In a previous company our
concept on SQL was that it was used for very simple work, (i.e. insert,
update, delete, select, etc). The applications we wrote did the bulk
of the work. We had very limited DTS's wrtten and stored procs were
very small.

In the company I've been working at for the last year, we have two
different mindsets on this issue (to be honest, the numbers of people
who feel like I do have dwindled, we've lost some of our DotNet
developers in the last few months). A very large amount of work is
being developed in SQL and even where our DotNet applications are
concerned, I have seen some push for putting a lot of the work into the
stored procs instead of having them be simplistic like I mentioned in
the previous paragraph. I have seen stored procs called by dot net
apps that call other stored procs, that call others, etc. Some of
these procs are like minature apps in of themselves.

I have a hard time wrapping my brain around why anyone would do this.
I believe that this type of design is problematic for maintainence at
the very least. But I would think it puts an unnecesary burden on SQL
too. I just don't know how to prove it. When I've mentioned this,
some of the feedback I get is that my concept would cause network
traffic that is unnecessary (i.e. multiple stored proc calls, etc).
Again, I am unsure how to test/verify such a claim.

I would think the best approach is to have your business logic stay in
DotNet if you have a DotNet app. Obviously if you have a process that
doesn't get put into an application at all, then I believe the logic
should stay in SQL. I do question the necessity of having that type of
work happen as often as I'm seeing it though. DotNet can be used to
write pretty much any type of application that you would do in SQL.

I'm curious as to how other groups approach this issue? Any feedback
at all - regardless of how it would be in regards to my own opinion on
this subject would be much appreciated.

.

Relevant Pages

  • Re: Sql / Dot Net General Discussion
    ... My primary experience is developing applications using VB or DotNet. ... have some sql skills but they are limited. ... We had very limited DTS's wrtten and stored procs were ... apps that call other stored procs, that call others, etc. ...
    (microsoft.public.dotnet.general)
  • Re: A new paradigm
    ... whereas I come from a dotnet background - thick apps and asp.net. ... whom are predisposed to SQL, tending toward SQL Server, MySQL, or ... By far the easiest database to adopt once you ... if the setup was available as a browser page or a Windows GUI screen ...
    (comp.databases.pick)
  • Pass-thru SQL performance vs Stored Proc
    ... answers to my question searching Google Groups. ... pass-thru SQL code? ... I thought I read somewhere that SQL-Server will cache in-line SQL calls ... Right now all our code is in stored procs. ...
    (microsoft.public.sqlserver.programming)
  • Re: Smartest way toa add records manually
    ... or dozens of specific stored procs for Add, Update, Delete to support ... ADO and MS Access GUI make it so easy to tie SQL to ... Objects for Ole instead of ADO) and never had SQL in the User interface ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Pass-thru SQL performance vs Stored Proc
    ... > pass-thru) SQL helps. ... Right now all our code is in stored procs. ... In general, always use stored procedures. ... > I thought I read somewhere that SQL-Server will cache in-line SQL calls ...
    (microsoft.public.sqlserver.programming)