Hi Frans ,
> -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Frans Bouma > Sent: Thursday, 22 September 2005 4:29 PM > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Business logic > > > In environments with lots of applications accessing the > > same database they also add more value. (Though this can > > backfire in case of testing changes to stored procs ) > > This is IMHO not true. The simple reason for this is that once you > have a proc which is used by multiple apps, you can't > change it if it needs a new parameter/different type/updated resultset, > because it will break a lot of apps, and perhaps these > aren't written in-house. So what do you do? You add a new one. After a > couple of years, how do you think your db will look like? It is possible in some environments , though as I said it requires retesting applications for each change. Though obviously it is something that does not scale to lots of users, but I can see a strongly managed environment with 3-4 or so apps working quite well. > > > In Environments with good DBA's responsible for > > managing the stored procs they are easier to maintain. > > The procs maybe, but that's just half of the story. How about the > code calling the procs? Ever written an n-tier application > with procs? Yep , I do lots of n Tier stuff and I don't used procs. My first line stated that they are an extra hassle for this environment. > So when a proc had to change, you not only had to change the > proc but also the calling code? The proc is then managed by > the DBA, but the calling code isn't. True but when procs change , you don't always need to change the application ( ie splitting tables ) . You also have to balance it against developers killing the DB with bad SQL . We have all seen this. > > What if the DBA is not available that day? Or has other ideas > about the interface / signature of the proc? Not fun. It will > slow down development for no real reason. Environment I worked in had 10 DBA's and they had 1 rostered on level 2 support each day . And yes it does slow development , though often the result is superior. Regards , Ben > > > In environments where the SQL is managed by the > > developers they are a hindrance to the operators who have to > > add the scrips to production each time they change. > > True. > > FB > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com ##################################################################################### Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. THIS COMPANY NAME and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Thank You. ##################################################################################### ##################################################################################### This email has been scanned by MailMarshal, an email content filter. ##################################################################################### =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
