Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

The Zero to N Parameter Problem (Sql Server 2005 and Up -- Update) Expand / Collapse
Author
Message
Posted Monday, December 16, 2013 12:13 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: 2 days ago @ 9:58 AM
Points: 36,995, Visits: 31,517
In rather stark contrast to what other folks have suggested about the use of XML to pass parameters, I usually wince at the thought. Because of "Tag Bloat", I concern myself with the extra I/O on all the systems and "pipes" from the end user to the database especially on systems that have a high hit rate. Because most people forget about it, I also concern myself with the need to de-entitize XML data for special characters and the fact that takes some bit of extra resources to accomplish.

Don't get me wrong. I think that CSV parameters are horrible even if proper CSV formatting is used instead of the formatting travesty that CSV has come to mean but if one does a comparison of methods using typical "simple" parameters, which consitute much of the parameter traffic, I'd rather use CSV because it causes much less traffic on the I/O systems across the board.

In case you're wondering, I'd like to see a return of the very sleek ASCII control characters to pass parameters with but no one will go there for multiple reasons... humans can't figure out what the "little square boxes" in Notepad mean and it's not likely that software providers will ever make such control character usage a standard because humans don't like to see such things as FS, GS, RS, or US in their transmission text. And, yes, passing column meta-data would be just as easy.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1523393
Posted Monday, December 16, 2013 12:31 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, August 11, 2014 5:11 AM
Points: 2, Visits: 9
I think this use case is better managed using client side dynamic sql generation. I'm not talking about concatenating strings to build the sql statement. I'm refering to using ORM's such as EntityLite https://github.com/jesuslpm/EntityLite:

for example:

var orderIds = new List<int> { 10248, 10248, 10250 };
var orders = dataService.OrderRepository.CreateQuery(Projection.BaseTable)
.Where(OrderFields.OrderId, OperatorLite.In, orderIds)
.ToList();

Advantages:
* No XML parsing
* No table variables
* Efficiency
* Easier

Limitations:
* Max number of id = max number of allowed parameters.

I think stored procedures are better suited for set based modifications, but not for perform dynamic queries.

Post #1523401
Posted Wednesday, December 18, 2013 7:59 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: 2 days ago @ 9:58 AM
Points: 36,995, Visits: 31,517
jesuslpm (12/16/2013)
I think this use case is better managed using client side dynamic sql generation. I'm not talking about concatenating strings to build the sql statement. I'm refering to using ORM's such as EntityLite https://github.com/jesuslpm/EntityLite:

for example:

var orderIds = new List<int> { 10248, 10248, 10250 };
var orders = dataService.OrderRepository.CreateQuery(Projection.BaseTable)
.Where(OrderFields.OrderId, OperatorLite.In, orderIds)
.ToList();

Advantages:
* No XML parsing
* No table variables
* Efficiency
* Easier

Limitations:
* Max number of id = max number of allowed parameters.

I think stored procedures are better suited for set based modifications, but not for perform dynamic queries.



My experiences with the code that some ORMs (mostly Link2SQL... .Net Framework seems to be ok) produce has been less than pleasant. They tend to lean towards using NVARCHAR constants for character based data instead of using the datatype (VARCHAR) of the table column and that means, of course, index scans at best because of the datatype mismatch and datatype precidence.

I've also found that the code they produce can be horribly bulky and inefficient even for typical C.R.U.D. They will many times include wierd sub queries that return way too many columns and produce totally unnecessary self joins as a result.

Of course, finding those performance and resource usage nightmares is a wee bit more difficult that finding performance challenged stored procedures and fixing them requires redeployment of front-end code.

Constructing well-written injection-proof dynamic SQL for things like "catch all" queries just isn't that much more difficult and it makes it easy to tune the queries as the scale of a database increases.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1524147
Posted Friday, April 4, 2014 3:56 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, August 11, 2014 5:11 AM
Points: 2, Visits: 9

>> My experiences with the code that some ORMs (mostly Link2SQL... .Net Framework seems to be ok) produce has been less than pleasant. They tend to lean towards using NVARCHAR constants for character based data instead of using the datatype (VARCHAR) of the table column and that means, of course, index scans at best because of the datatype mismatch and datatype precidence.
<<

EntityLite uses the same type for the parameter as the column. If the column is varchar the parameter is varchar.

>> I've also found that the code they produce can be horribly bulky and inefficient even for typical C.R.U.D. They will many times include wierd sub queries that return way too many columns and produce totally unnecessary self joins as a result. <<

EntityLite produces very efficient, controlled and predictable SQL code. EntityLite is different from other ORM's, because instead of being object oriented, EntityLite embraces the relational model.

>> Constructing well-written injection-proof dynamic SQL for things like "catch all" queries just isn't that much more difficult and it makes it easy to tune the queries as the scale of a database increases. <<

Server side dynamic sql is very difficult to maintain and tune. And using a ORM helps you to prevent sql injection attacks.

http://www.codeproject.com/Articles/753796/i-nercya-EntityLite-A-Lightweight-Database-First-M
Post #1558415
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse