|
I'm glad I'm not the only one here who dislikes stored procedures (or at least the blind overuse of them).
Let me preface:
Before .net I did most of my database application programming with SQL embedded in C, either with Oracle (PRO*C) or RDB.
But at one point I had to work on a project that used SQL Server (6, as I recall) and ESQL was not yet available so we had to use a horrible (consultant-written) library of ODBC routines. The result was that the only way to have transactions was to use stored procedures.
No one was happy about it and thought very nasty thoughts about the sales monkeys who said we'd do it.
While I realize that newer versions of SQL Server offer better security and reliability, I continue to distrust stored procedures:
A) While installing some of my stuff at a client's site, the client asked if I could make a slight change; I did, it was just a small change to a stored procedure... a change to production code outside of source control. I did remember to check in the updated code when I returned to the office, but I realized that any (properly authorized) person could change any of the procedures, perhaps maliciously. Such changes are much more difficult with compiled code.
B) Several times a stored procedure just disappeared! I have no idea how. This either doesn't happen with compiled code, or at least the program won't run at all if it does.
Performance:
A) I can neither confirm nor deny whether or not procedures are faster than queries in strings. I suspect they are, though at best it's only due to preparation time.
Unless you have a procedure that gets called a whole lot (which may well be the case with a Web page), I doubt it matters.
If a procedure gets called less frequently then you're not benefiting from any performance improvement.
If the preparing of a particular SQL statement proves to be a bottleneck, by all means wrap it in a stored procedure.
B) But also remember that a parameterized ADO.net SqlCommand, once prepared, can be reused many times.
So if you have a Windows Service that needs to execute a particular statement many times during its execution (which should last months) it need only prepare the statement once, just like a stored procedure.
On the other hand, if you repeatedly create and dispose an SqlCommand that executes a stored procedure lose out on much of the benefit of having pre-compiled the code in the stored procedure.
C) One of the benefits of a stored procedure is that you can perform some logic on the data without passing it out of and back into the database, but I wonder what percentage of stored procedure actually involve that.
D) Add to that the recent post that pointed out that if you begin the names of your stored procedures with "sp_", SQL Server wastes time looking for it among the system procedures.
E) I have also worked with people who insisted that "metadata" (stored procedured, functions, etc.) bogged down the database. (Crazy as that seems.)
Other points:
A) If I have an application installed at several client sites I can check the installed versions with directory commands.
B) I can deploy a change to client systems with copy.
C) A database restore won't wipe out SQL code in compiled code.
D) I have no idea why someone would write a stored procedure that merely returns a table of data; use a view for that.
I also use quite a few inline table-valued functions; they combine the best of both views and stored procedures.
Closing:
Don't just use stored procedures unthinkingly:
If the statement is a proven bottleneck, first try improving the statement, only make it a stored procedure as a last resort.
A pre-compiled piece of crap is little better than an ad hoc piece of crap. (And it may be more visible to the client.)
Conceptually, a "procedure" has more than one step, and perhaps control statements; if your code is one simple statement I doubt it should be a stored procedure.
"Use the right tool for the right job." -- Scotty et al
|
|
|
|
|
5ed ! It's a great post. Thanks
|
|
|
|
|
I've got to admit, I'm one of the proc adherants. I put a lot of work into the procedures. With the "one liners" that simply do the CRUD I use procs because I have a code generator that creates the procs and the classes to service them. However most of my work goes into serious crunching of numbers in high volume and for this we need to use procs.
I had not considered the security issues of installed apps (I work for a corporate and you need 53 bits of paper to enter the presence of the production servers) based on procedures. I was aware thae using a framework like nHiberante can give you a DB agnostic application but would not consider using it for my apps.
Restore comes under the same criteria as the production server access! I have lost s a proc but thought it was just me, there you go! Having said that my DAL has a GetTableSQL and an ExecuteSQL so I'm not welded to procs.
Thank you for the food for thought, I will no longer go blindly forward!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Frans bouma has something to say about stored procedures here[^]. It's worth reading.
|
|
|
|
|
Thanks, I've been looking for that article for a while. Read it several months ago.
|
|
|
|
|
Togakangaroo wrote: fewer applications to maintain
SP can be harder to maintain, as it's not contained in a visual studio like solution or project. You literally have to search through all 150 SPs to find business logic, and the capability of renaming of column doesn't help.
|
|
|
|
|
Just use LINQ
|
|
|
|
|
Amen to that my brother
Harvey Saayman - South Africa
Junior Developer
.Net, C#, SQL
you.suck = (you.passion != Programming)
|
|
|
|
|
I'm wondering whether or not Linq is the new embedded-SQL, I might be interested if so.
|
|
|
|
|
I have personally made it my mission to get rid of all but needed stored procs by using LINQ. And guess what, tomorrow I can swap to Oracle* or MySQL* and use the same code!
* Given they have working LINQ query providers.
|
|
|
|
|
I, like a lot of people, use stored procs extensively, mostly on reasonably large databases. Some of the reasons:
Network performance - why push extra data over the network (sp name + parameters as opposed to long sql statement)
Reuse, maintainability and consistency - if you have two applications doing the same query (perhaps with complex joins) and you need to change the query you change (and release) 1 proc, not 2 applications. You also ensure that all versions of the query are consistant and performance tuned - different developers have different skills, not everyone is good at sql.
Performance - I know that paramterised queries are cahced etc, but there are more opportunities for tuning with stored procs (some people may dispute that, thats their opinion)
There are other pros and cons, and everyone has differing opinions. I am possibly biased in that I have been contracting (mostly at large international financials) for many years, and all PRODUCTION applications have to access the database using stored procedures. This simplifies upgrades and bug fixes as you roll out a stored procedure to 1 server (possibly replicated) rather than several applications to users around the globe.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Ashfield wrote: reasonably large databases
It's the statement that matters, not the size of the database.
Ashfield wrote: as opposed to long sql statement
You only need to do that once per application run.
Ashfield wrote: 1 proc, not 2 applications
One DLL, not two EXEs.
Ashfield wrote: users around the globe
Web Service?
|
|
|
|
|
PIEBALDconsult wrote: It's the statement that matters, not the size of the database.
Not totallly, you can get anyway with any old crap on small databases, but I only mentioned database size as background.
PIEBALDconsult wrote: You only need to do that once per application run.
What, even a paramaterised query?
PIEBALDconsult wrote: One DLL, not two EXEs.
Still have to deploy to all users
PIEBALDconsult wrote: Web Service?
Performance?
Sorry, eveyone is entitled to their opinion, I am merely giving my two pennth based on my experience. Other people, as I said, have different opinions and I am fully aware that the financial industry differs in working practices from other industries.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Stored procedures are great, but they are not magical.
You might sometimes get a slight speed benefit from using stored procedures, but the potential is very limited. You can easily get much more speed from other changes.
If you want to keep as much of the programming as possible in one place, the database is definitely not the place. Robust and maintainable code is better written in a compiled and object oriented language. Your stored procedures should query data, and little more.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
I gave you a 5 even though I don't agree with
Guffa wrote: stored procedures should query data
|
|
|
|
|
I use store procedures a lot, never thought it´s a bad idea.
It makes my work better organized.
Good Luck
nelsonpaixao@yahoo.com.br
|
|
|
|
|
Hi,
I have build a class with a Thread as a member. The thread's function is also defined within the class and I start the thread at the class' constructor. - So far so good ...
Now my question: I created a instance of this class and I've noticed that the internal Thread keeps running after the class instance goes out of scope.
I can see that the only way to stop the Thread is to implement a "public Teminate()" method that kills the Thread.
I wanted to implicity shut down the internal Thread so I tried to implement Finalizer. this didnt work for me - the Internal thread kept running and the Finalizer never called
Any ideas how to solve this issue? It also interesting to know why such behvior occures.
Many thanks!!
Ofer
|
|
|
|
|
ofeririko wrote: Any ideas how to solve this issue?
Yes. I suggest you start here[^]. After you have exhausted that resource there are many, many others available on the internet on this subject.
led mike
|
|
|
|
|
ofeririko wrote: I created a instance of this class and I've noticed that the internal Thread keeps running after the class instance goes out of scope.
Yes, mainly for two reasons.
1. A thread doesn't die just because there is no reference to it's class. It's referencing the class itself, so it's not going to be garbage collected.
2. Nothing happens to the object when the variable referencing it goes out of scope. Absolutely nothing. When an object becomes unreachable it's up for garbage collection, but the garbage collector doesn't care about scope at all, only usage. The concept of scope is only relevant to the compiler.
ofeririko wrote: I can see that the only way to stop the Thread is to implement a "public Teminate()" method that kills the Thread.
The well behaved way of stopping a thread is to tell it to stop, and let it exit out of it's main method by itself. Changing the value of a volatile variable that the thread is polling, is one way of doint that.
ofeririko wrote: I wanted to implicity shut down the internal Thread so I tried to implement Finalizer. this didnt work for me - the Internal thread kept running and the Finalizer never called
Of course not, the Finalizer is only called once the garbage collector notices that the object is up for garbage collection, but as the thread is referencing the object, it never will be.
If you want to control the life cycle of an object, you should implement the IDisposable interface.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
hi friends
i have a question about object oriented(class inheritance)
i have a windows application with c# that in this application i have 2 forms. these 2 forms have few methods i show you below.
========> form1
public partial class form1:Form
{
public form1()
{
InitializeComponent();
}
public void change_value_label(string new_value)
{
lbl.Text=new_value;//this label defined as private controll for this form
}
}
=========>form2
public partial class form2:Form
{
public form2()
{
InitializeComponent();
}
private void subject_Load(object sender, EventArgs e)
{
//in this area code i want to write a code that call change_value_label method of form1 , but i can't
// if i create a new object of form1 then i can call the method but with this way i cannot change the value of the label on form1
//and if i declare change_value_label method on form1 as static method then on the method i cannot access to the label because this controll is not static and i //cannot define the label as static control
//please tell me what do i have to do to solve this problem?
}
}
form1 and form2 are showing at te same time because this two forms are children forms.
thank u.
nobody help you...
you have to help you yourself
and this is success way.
|
|
|
|
|
I'm not sure what this has to do with inheritance - both forms are inheriting from System.Windows.Forms.Form
Anyway, I answered a similar question a few minutes ago here[^].
If both forms are child forms then you may need to use events as well.
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
|
|
|
|
|
Colin[^] has a good article on his blog here[^]
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
|
|
|
|
|
Add a handler for the load event of form2 in form1 and do whatever you need to do. This is the easiest solution and it is OO as well.
To do so, create a method or property in form1 and send it the instance of form2. Then within form2 create an event handler for the load event of form1 and do whatever you need to--change the label.
|
|
|
|
|
I am attempting to modify a file that a program has a lock on which is write-only. Is there some way i can do this in C#?
Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer.
-Fred Brooks
|
|
|
|
|
StevenWalsh wrote: Is there some way i can do this in C#?
There shouldn't be. Other programs usually have locks on files for a reason.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|