stored procedures Vs dynamic SQL
-
I have a question about stored procedures Vs dynamic SQL. I'm a noob but from the googling I've done this seems to be a hot topic so I dont want to start an arguement but I'm stuck. The website I am working on has a data access layer that takes in a SP name & parameters. It runs the SP and returns the resulting data to the page that requested it. This is easy & quick to maintain for me. However, my users want to be able to search the customer using search criteria parameters that can be different each time. By that I mean they want to be able to search for customers using whatever data they have. Sometimes they will have a last name, other times a last name & birth date, sometimes a phone number and a first name. This doesnt seem to lend itself to a SP - the parameters change each time so the solutions seem to be: 1. A SP that has every criteria in it and use LIKE '%%' when the customer doesnt use one of them 2. Have the data access layer dynamically build the required SQL and then insert it into the SP somehow. (Which sorta kinda sounds like SQL injection) 3. Build an SP for each group of search criteria (Name, DOB, Phone numbers, TIN) and then only allow the users to use one search criteria group at a time. Neither solution sounds that great to me. (There may be others but like I say I'm a noob) Which leads me to think that maybe in this case I should use Dynamic SQL - e.g. have the data acccess layer create the SQL statement and then execute it against the database without using an SP. But then that breaks my rule of only using SP (which I originally created cos I thought SP ran quicker but then I read that according to some guys at MS that dynamic SQL runs as quickly as SP in the .Net environment) so now I'm confused.
-
I have a question about stored procedures Vs dynamic SQL. I'm a noob but from the googling I've done this seems to be a hot topic so I dont want to start an arguement but I'm stuck. The website I am working on has a data access layer that takes in a SP name & parameters. It runs the SP and returns the resulting data to the page that requested it. This is easy & quick to maintain for me. However, my users want to be able to search the customer using search criteria parameters that can be different each time. By that I mean they want to be able to search for customers using whatever data they have. Sometimes they will have a last name, other times a last name & birth date, sometimes a phone number and a first name. This doesnt seem to lend itself to a SP - the parameters change each time so the solutions seem to be: 1. A SP that has every criteria in it and use LIKE '%%' when the customer doesnt use one of them 2. Have the data access layer dynamically build the required SQL and then insert it into the SP somehow. (Which sorta kinda sounds like SQL injection) 3. Build an SP for each group of search criteria (Name, DOB, Phone numbers, TIN) and then only allow the users to use one search criteria group at a time. Neither solution sounds that great to me. (There may be others but like I say I'm a noob) Which leads me to think that maybe in this case I should use Dynamic SQL - e.g. have the data acccess layer create the SQL statement and then execute it against the database without using an SP. But then that breaks my rule of only using SP (which I originally created cos I thought SP ran quicker but then I read that according to some guys at MS that dynamic SQL runs as quickly as SP in the .Net environment) so now I'm confused.
If you want to continue using SPs, you could always check the value of the parameter to see if it is null or not in the where clause. For instance:
SELECT .... FROM table1 WHERE (Col1 = @Col1 OR @Col1 IS NULL) AND (Col2 = @Col2 OR @Col2 IS NULL)Deja View - the feeling that you've seen this post before.
-
If you want to continue using SPs, you could always check the value of the parameter to see if it is null or not in the where clause. For instance:
SELECT .... FROM table1 WHERE (Col1 = @Col1 OR @Col1 IS NULL) AND (Col2 = @Col2 OR @Col2 IS NULL)Deja View - the feeling that you've seen this post before.
-
Effectively yes because it evaluates the boolean to true. If you want to shortcircuit it, you can swap the order of the tests around.
Deja View - the feeling that you've seen this post before.
-
Effectively yes because it evaluates the boolean to true. If you want to shortcircuit it, you can swap the order of the tests around.
Deja View - the feeling that you've seen this post before.
-
I have a question about stored procedures Vs dynamic SQL. I'm a noob but from the googling I've done this seems to be a hot topic so I dont want to start an arguement but I'm stuck. The website I am working on has a data access layer that takes in a SP name & parameters. It runs the SP and returns the resulting data to the page that requested it. This is easy & quick to maintain for me. However, my users want to be able to search the customer using search criteria parameters that can be different each time. By that I mean they want to be able to search for customers using whatever data they have. Sometimes they will have a last name, other times a last name & birth date, sometimes a phone number and a first name. This doesnt seem to lend itself to a SP - the parameters change each time so the solutions seem to be: 1. A SP that has every criteria in it and use LIKE '%%' when the customer doesnt use one of them 2. Have the data access layer dynamically build the required SQL and then insert it into the SP somehow. (Which sorta kinda sounds like SQL injection) 3. Build an SP for each group of search criteria (Name, DOB, Phone numbers, TIN) and then only allow the users to use one search criteria group at a time. Neither solution sounds that great to me. (There may be others but like I say I'm a noob) Which leads me to think that maybe in this case I should use Dynamic SQL - e.g. have the data acccess layer create the SQL statement and then execute it against the database without using an SP. But then that breaks my rule of only using SP (which I originally created cos I thought SP ran quicker but then I read that according to some guys at MS that dynamic SQL runs as quickly as SP in the .Net environment) so now I'm confused.
SQL Server compiles an execution plan for a query the first time it's run. That plan is then cached and reused. It will be discarded either when it's aged out of memory (i.e. there was enough memory pressure for query plans to be removed from memory, and this was less recently used/important than other cached plans) or when the statistics on the index columns have changed enough to force a recompile, or you add or remove some indexes on tables used in the query. The same is true for stored procedures - their query plans are just weighted higher than dynamic SQL. It's got nothing to do with the .NET environment, it applies to all interfaces. I'm concerned that queries using
LIKE '%%'orOR @param=''etc will have a query plan constructed based on the first set of arguments supplied, but which will then be a poor plan for a different set of arguments, and SQL Server will reuse that initial plan rather than construct a better one. This is something I don't have data on, however - you should profile this. In this case I think dynamic SQL could be better. You can mark a stored procedure to be recompiled every time by specifyingWITH RECOMPILE. However, you incur the overhead of computing the plan every time; caching the dynamic SQL's plan might work better. If your query does not use parameters, SQL Server will attempt to auto-parameterise the query so that it can reuse the plan for more queries. That is, it will replace explicit literal values with parameters. However, it may be better to mark the parameters yourself if there are literals in the query which don't change. Stored procedures are useful as a security boundary - you can GRANT a user permission to EXECUTE a stored procedure even if they're denied permission to perform the operations of the SP directly.Stability. What an interesting concept. -- Chris Maunder
-
Short circuiting simply refers to the case where a boolean condition halts before it evaluates the next part. A simple C# demonstration should show this:
DateTime? dtToday = null; if (dtToday == null || dtToday == DateTime.Now)The second part never executes because dtToday is null and so the conditions for an or statement is satisfied. In the case of an AND condition, the second part of the statement would not be executed if the first part is false.Deja View - the feeling that you've seen this post before.