views:

20

answers:

1

I just switched groups and what they currently do is have their middle tier pass XML to the procedures and then use xquery/xpath to parse the xml and use it to get information and return it back to the app (RETURN XML). I was just curious if others use a similar process or if they just pass the data directly into the procedures. I really like how flexible it is, but it really makes the procedures ugly because you have to parse the XML, query your data, and format the data into xml (formatting is trivial with SQL 2008).

My main concern is with performance. I have to parse the xml and put it into tmp tables or table variables so that I can use it in my queries.

Any thoughts?

A: 

I have had similar approach, only for webservices, not stored procedures. I would say, that it's not a good practice and should be avoided unless absolutely needed.

Main problem probably isn't performance, but fact, that you are creating GIGO (garbage-in-garbage-out) component, where you don't have any formal contract between caller and procedure. Which means that wrong data on input/output can go unnoticed and you will have hell of a debugging.

And yes, you will get some performance hit too (probably on both layers).

PiRX
@PiRX: what if the XML data is strongly-typed (has a set of schemas associated with it)?
John Saunders
It's better, but still, for most cases it's overkill. Don't get me wrong - I'm sure there are cases when passing XML to SP is valid, like when you need to pass complex structure as parameter. But if you use it for ALL procedures, then definitely there is something wrong.
PiRX