Every sample I've seen uses stored procedures. I've adopted an old application written in Classic ASP that uses inline SQL. This is an obvious issue, so I need to convert it to safer code. The client does not wish that I use stored procedures in this application, so is there a way to run parameterized queries without stored procedures?
Thanks
Yes, there is. Have a look at some of these examples:
http://www.securestate.blogspot.com/2008/09/classic-asp-sql-injection-prevention_30.html
http://www.userfriendlythinking.com/Blog/BlogDetail.asp?p1=7013&p2=119&p7=3001
Is there any reason why the client doesn't want to use stored procedures? It is much easier to use stored procedures both on the database level as well as in your source code. You should get query plan caching on your inline query if you use the second method from above, but depending on what you are doing you might be better off with simple sprocs if you can convince your client that it's ok to use them. If all else fails the links above are pretty solid, especially the second one.
Related
I have to make my stored procedures written in SQL to be generic, so that they can be used in different versions of SQL (also MySQL if possible). I think it can be done if the scripts are written according to ANSI standards. But I have to convert large procedures. There is no tool for direct conversion. Is there any set of rules which can be followed to perform this conversion?
I have found a tool to validate scripts # http://developer.mimer.com
But this will be very time consuming as I have large SP's and I think by using some rule book, this task can be done in a shorter time.
There is no generic stored procedure language.
If you need something to work across database platforms, you would be better to implement the SP functionality in code, using ANSI standard SQL for the database access.
I'm pretty new to SQL world. Here are my questions:
What are the benefits of stored procedured over normal SQL statement in applications?
Does stored procedure help eliminates SQL injection?
In Microsoft SQL Server it is called stored procedure. How about in Oracle, MySQL, DB2, etc.?
Thanks for your explanation.
Stored procedures only directly prevent SQL injection if you call them in a paramerized way. If you still have a string in your app with the procedure name and concatenate parameters from user input to that string in your code you'll have still have trouble.
However, when used exclusively, stored procedures let you add some additional protection by making it possible for you to disable permissions to everything but the EXEC command. Aside from this, parameterized queries/prepared statements are normally cached by the server, and so are just like a stored procedure in nearly every respect.
In spite of this, stored procedures have two big advantages for larger enterprises:
They allow you to define an application interface for the database, so that the system can be shared between multiple applications without having to duplicate logic in those applications.
They move the sql code to the db, where you can easily have an experienced DBA tune, update, and otherwise maintain it, rather than application developers who often don't know exactly what they're doing with database code.
Of course, these advantages aren't without cost:
It's harder to track changes in source control
The database code is far separated from the code that uses it
Developer tools for managing many stored procedures are less than ideal (if you've ever open the stored procedures folder in management studio to find 200 procedures for a database, you know what I'm talking about here).
Some of the benefits that I consider when using stored procedures
Stored procedures encapsulate query code at the server, rather than inside your application. This allows you to make changes to queries without having to recompile your application.
Stored procedures can be used for more well defined application security. You can Deny all rights on the base tables, grant execute only on the procs. This gives you a much smaller security footprint to manage.
Stored procedures are compiled code. With the latest versions of MSSQL the server does a better job of storing execution plans - so this isn't as big of an issue as it used to be, but still something to consider
Stored procedures eliminate SQL injection risk ONLY when used correctly. Make sure to use the parameters the right way inside the stored proc - stored procs that are just executing concatenated dynamic SQL inside them aren't doing anyone any good.
For the most part yes, SQL injection is far less likely with a stored procedure. Though there are times when you want to pass a stored procedure some data that requires you to use dynamic SQL inside the stored procedure and then you're right back where you started. In this sense I don't see any advantage to them over using parameterized queries in programming languages that support them.
Personally I hate stored procedures. Having code in two disjointed places is a pain in the ass and it makes deploys that much more complicated. I don't advocate littering your code with SQL statements either however as this leads to it's own set of headaches.
I recommend a DAL layer implemented one of two ways.
My favorite, use an object
relational management system (ORM).
I've been working with nHibernate
and I absolutely love it. The
learning curve in steep but
definitely worth the payoff in my
opinion.
Some kind of mechanism for keeping
all your SQL code in one place.
Either some sort of query library
you select from or a really
structured set of classes that
design the SQL for you. I don't
recommend this way since it's
basically like building your own ORM
and odds are you don't have the time
to do it correctly.
Forget stored procedures. Use an ORM.
One way in which stored procedures (ones which do not use dynamic SQL) can make the whole application more secure is that you can now set the permissions at the stored procedure level and not at the table level. If you do all of your data access this way (and forbid dynamic sql!) this means users can not under any circumstances do amnything to the database that is not in a stored proc. Developers always want to say that their application code can protect against outside threats, but they seem to forget that inside threats are often far more serious and by allowing permissions at the table level, they are at the mercy of any user who can find a way to directly query the database outside the application (another reason why in large shops only two or three people at most have production rights to anything in the datbase, it limits who can steal information).
Any financial system that uses anything except stored procs for instance is completely open to internal fraud which is a violation of internal controls that should prevent fraud and would not pass a good audit.
Stored procedures allow you to store you sql code in a location outside of the application. this gives you the ability to:
Change the SQL Code without recompiling/redistrubuting the application
Have multiple applications use the same stored procedure to access the same data.
Restrict users from having access to read/write to tables directly in the database.
From a development perspective it also allows the DBAs/database programmers to work on sql code without having to go through application code to work on it. (separation of responsibilities essentially).
Do stored procedures protect against injection attacks? For the most part yes. In sql server you can create stored procedures which are not effective against this, mainly by using sp_executesql. Now this doesn't main that sp_executesql is a security hole, it just means that more precaution needs to be taken when using it.
This also does not mean that stored procedures are the only way to protect against this. You can use parameritized sql to accomplish the same task of protecting against sql injection.
I do agree with other people stored procedures can be cumbersome, but they have their advantages too. Where I work, we have probably 20 different production databases for various reasons (don't ask). I work on a subset of maybe three, and my teammate and I know those three really really well. How do stored procedures help us? People come to us and when they need to grab that information out of those databases, we can get it for them. We don't have to spend hours explaining the schemas and what data is de-normalized. It's a layer of abstraction which allows us to program the most efficient code against the databases we know. If this isn't the case for you, then maybe stored procedures aren't the way to go, but in some instances they can add a lot of value.
We are developing a Visual Studio.NET 2008 application with Oracle 9i as backend. Is it true that the usage of Stored procedures would be faster than Inline SQL ? This is a debate with my co-programmers.
We are using ODP.NET (Oracle Data Provider for .NET) from Oracle.
Thanks.
While I am tempted to answer "no" or "I don't think so", the only real way to know the answer to this question is to go and measure it yourself. Use a profiler like JetBrains dotTrace, and TOAD's own profiler, to find out.
All other answers are speculative.
It should be. When you send inline SQL to database, the engine must parse it and execute. Stored procedures are being parsed (and compiled) at creation time. So at least you are gaining parsing time.
I would expect stored procedures to be faster in almost all cases.
But it mainly depends on your code.
If for example you get a resultset from your database and then use this data to perform other queries, you'll end up with a lot of overhead in your network traffic. This is especially true if you forget to use a single connection for the requests.
It could then be more efficient to use a single stored procedure to return the agregated data (if possible of course).
It will be faster if you build your stored procs (PL/SQL packages) in such a way that less data will be transferred between the database and the client.
Jon Limjap said: "All other answers are speculative."
There's much truth to this statement. There are so many factors: how's the DB server set up? How's the network speed/reliability? How's the SQL? How's the PL/SQL? I could write really slow SQL and/or PL/SQL if I wanted to (and have, inadvertently, on past projects!). So if you can, try both out.
First of all there is a partial question regarding this, but it is not exactly what I'm asking, so, bear with me and go for it.
My question is, after looking at what SubSonic does and the excellent videos from Rob Connery I need to ask: Shall we use a tool like this and do Inline queries or shall we do the queries using a call to the stored procedure?
I don't want to minimize any work from Rob (which I think it's amazing) but I just want your opinion on this cause I need to start a new project and I'm in the middle of the line; shall I use SubSonic (or other like tool, like NHibernate) or I just continue my method that is always call a stored procedure even if it's a simple as
Select this, that from myTable where myStuff = StackOverflow;
It doesn't need to be one or the other. If it's a simple query, use the SubSonic query tool. If it's more complex, use a stored procedure and load up a collection or create a dataset from the results.
See here: What are the pros and cons to keeping SQL in Stored Procs versus Code and here SubSonic and Stored Procedures
See answers here and here. I use sprocs whenever I can, except when red tape means it takes a week to make it into the database.
Stored procedures are gold when you have several applications that depend on the same database. It let's you define and maintain query logic once, rather than several places.
On the other hand, it's pretty easy for stored procedures themselves to become a big jumbled mess in the database, since most systems don't have a good method for organizing them logically. And they can be more difficult to version and track changes.
I wouldn't personally follow rigid rules. Certainly during the development stages, you want to be able to quickly change your queries so I would inline them.
Later on, I would move to stored procedures because they offer the following two advantages. I'm sure there are more but these two win me over.
1/ Stored procedures group the data and the code for manipulating/extracting that data at one point. This makes the life of your DBA a lot easier (assuming your app is sizable enough to warrant a DBA) since they can optimize based on known factors.
One of the big bugbears of a DBA is ad-hoc queries (especially by clowns who don't know what a full table scan is). DBAs prefer to have nice consistent queries that they can tune the database to.
2/ Stored procedures can contain logic which is best left in the database. I've seen stored procs in DB2/z with many dozens of lines but all the client has to code is a single line like "give me that list".
Because the logic for "that list" is stored in the database, the DBAs can modify how it's stored and extracted at will without compromising or changing the client code. This is similar to encapsulation that made object-orientd languages 'cleaner' than what came before.
I've done a mix of inline queries and stored procedures. I prefer more of the stored procedure/view approach as it gains a nice spot for you to make a change if needed. When you have inline queries you always have to go and change the code to change an inline query and then re-roll the application. You also might have the inline query in multiple places so you would have to change a lot more code than with one stored procedure.
Then again if you have to add a parameter to a stored procedure, your still changing a lot of code anyways.
Another note is how often the data changes behind the stored procedure, where I work we have third party tables that may break up into normalized tables, or a table becomes obsolete. In that case a stored procedure/view may minimize the exposure you have to that change.
I've also written a entire application without stored procedures. It had three classes and 10 pages, was not worth it at all. I think there comes a point when its overkill, or can be justified, but it also comes down to your personal opinion and preference.
Are you going to only ever access your database from that one application?
If not, then you are probably better off using stored procedures so that you can have a consistent interface to your database.
Is there any significant cost to distributing your application if you need to make a change?
If so, then you are probably better off using stored procedures which can be changed at the server and those changes won't need to be distributed.
Are you at all concerned about the security of your database?
If so, then you probably want to use stored procedures so that you don't have to grant direct access to tables to a user.
If you're writing a small application, without a wide audience, for a system that won't be used or accessed outside of your application, then inline SQL might be ok.
With Subsonic you will use inline, views and stored procedures. Subsonic makes data access easier, but you can't do everthing in a subsonic query. Though the latest version, 2.1 is getting better.
For basic CRUD operations, inline SQL will be straight forward. For more complex data needs, a view will need to be made and then you will do a Subsonic query on the view.
Stored procs are good for harder data computations and data retrieval. Set based retrieval is usually always faster then procedural processing.
Current Subsonic application uses all three options with great results.
I prefer inline sql unless the stored procedure has actual logic (variables, cursors, etc) involved. I have been using LINQ to SQL lately, and taking the generated classes and adding partial classes that have some predefined, common linq queries. I feel this makes for faster development.
Edit: I know I'm going to get downmodded for this. If you ever talk down on foreign keys or stored procedures, you will get downmodded. DBAs need job security I guess...
The advantages of stored procedure (to my mind)
The SQL is in one place
You are able to get query plans.
You can modify the database structure if necessary to improve performance
They are compiled and thus those query plans do not have to get constructed on the fly
If you use permissions - you can be sure of the queries that the application will make.
Stored procedures group the data and the code for manipulating/extracting that data at one point. This makes the life of your DBA a lot easier (assuming your app is sizable enough to warrant a DBA) since they can optimize based on known factors.
Stored procedures can contain logic which is best left in the database. I've seen stored procs in DB2/z with many dozens of lines but all the client has to code is a single line like "give me that list".
the best advantage of using stored procs i found is that when we want to change in the logic, in case of inline query we need to go to everyplace and change it and re- roll the every application but in the case of stored proc change is required only at one place.
So use inline queries when you have clear logic; otherwise prefer stored procs.
Say I have a stored procedure that returns data from a SELECT query. I would like to get a slightly different cut on those results depending on what parameters I pass through. I'm wondering whether it is better design to have multiple stored procedures that take one or no parameters to do this (for example, GetXByDate or GetXByUser), or one stored procedure with multiple parameters that does the lot (for example, GetX)?
The advantage of the first option is that it's simpler and maybe faster, but disadvantage is that the essence of the query is duplicated across the stored procedures and needs to be maintained in several places.
The advantage of the second option is that the query is only present once, but the disadvantage is that the query is more complex and harder to troubleshoot.
What do you use in your solutions and why?
The more complex stored procedures are more complex for the SQL server to compile
correctly and execute quickly and efficiently.
Even in the big stored procedure you have to either have to have several copies of the query or add lots of CASEs and IFs in it which reduce performance. So you don't really gain much from lumping everything together.
From my personal experience I also consider large SQL sp code with lots of branches more difficult to maintain that several smaller and straightforward sprocs.
You could consider using views and UDFs to reduce copy-pasting of the query code.
Saying that if you don't care about performance (intranet app, the queries are not that heavy, don't run that often) you might find having a universal sproc quite handy.
I would treat stored procedures much in the same way as I would a method on a class. It ought to do one thing and do it simply. Consider applying the same sorts of refactoring/code smell rules to your stored procedures that you would to your application code.
I prefer GetXByDate, GetXByUser, ... for simple stored procedures, on the basis they will require little maintenance anyway, and in this situation I think it is easier to maintain duplicate code than complicated code.
Of course, if you have more complicated stored procedures, this may not be true. GetAndProcessXByDate may be better reduced to GetXByDate, GetXByUser, ... which call another stored proc ProcessX.
So I guess the definitive answer is: it depends... :)
I second #tvanfosson.
However, I would add that you can do both: have a multi-use sproc (e.g. GetX) which contains the essential logic for a whole class of queries, and wrap it up in a series of smaller sprocs (GetXY, GetXZ) which execute the big one, passing in the appropriate parameters.
This means that you Don't Repeat Yourself, but you can also provide a simple interface to the client apps: an app which only ever calls GetXY doesn't have to know about GetXZ.
We use this approach sometimes.
One advantage of the single stored proc if you're using a generated C# data access layer like LinqToSQL a single class is generated to represent your resultset.
AJs approach gives you the best of both worlds. The pain of having to maintain repeated code across several sprocs cannot be overstated.
Build Sproc and UDF modules for common use, and call them from task-specific sprocs.
Who/what will be calling these stored procedures? I wouldn't write stored procedures for SELECT statements normally, precisely because there are lots of different SELECT statements you might want, including joins to other tables etc.