Hello (e-mail address removed),
The DataSet definitely *can* be faster...but the actual performance depends
on many more details than just the raw processing. If the client (where
the DataSet is created and used to create XML) is already heavily over-utilized
(e.g. CPU usage is at a premium), then doing the work in SQL Server will
be faster...
But the inverse is also true, if you have a heavily consumed DB Server, then
doing the work in teh DataSet makes even more sense. If both are under utlized
machines, they I would expect the DataSet to be faster. But understand that
performance is a complicated issue. If you are just counting how many CPU/File
IO cycles it takes, then DataSet probably wins but I can give you a "Its
always faster" stamp of approval.
This problem of perceived performance is especially problematic in web applications
as the machines that most companies use for web servers are usually under-powered
commidity hardware, so pushing additional CPU/FIle IO processing to the web
server may not be a good decision.
Lastly, understand that there are several ways of creating the XML in SQL
Server (both in 2000 and 2005). SQLXML tends to be problematic in my experience
as it hides some of its implementation to be done on the client even though
it tries to act as if it is being performed on the server, but this is not
true of the FOR XML syntax stuff.
So if I was forced (by gunpoint) to give an opinion based on what you have
explained, I'd suggest starting out with teh DataSet approach as it is more
straightforward (IMHO). But monitoring your app for CPU/IO usage will be
important to determine if it really is faster.
HTH
Thanks,
Shawn Wildermuth
Speaker, Author and C# MVP
http://adoguy.com