1

I am creating a very data intensive, high volume web site. Every aspect of the website is driven by interactions with the MSSQL DB that I am using. On one page there are 10-12 different resultsets that I need to utilize in my page. So I need to know the best practice when it comes to using Linq-to-SQL and multiple results sets with a web application.

Should I have it return multiple result sets, create classes that will then receive the data and utilize it that way or just call 10-12 Store Procedures and return the data to the previous generated LINQ To SQL Data Classes?

Thanks for your help everyone! I appreciate it!

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Reaction21
  • 661
  • 1
  • 5
  • 18

1 Answers1

1

Well as always the fewer trips to the database the better, but it all depends on whether or not that approach is maintainable and fits the architecture of your application. I personally have not worked on an application where the number of trips to the database was so important that I had to fetch everything up front, but each situation is different.

Josh
  • 68,005
  • 14
  • 144
  • 156
  • If are getting millions of hits per day to that page then you are getting 10-12 million hits to the DB on that page alone. How would I even determine or analyze if I would be better to wrap it in one send/receive message and then parse it out in the app code? – Reaction21 Jan 13 '10 at 07:46
  • Well since the ADO.NET providers are going to use connection pooling regardless of what you do, it really becomes simply a matter of network overhead. If the network connection between the web server and database is fast, it probably doesn't matter much. If it's remotely located, it could matter a lot. But the DB is going to do the same amount of work processing one command or a batch of commands. – Josh Jan 13 '10 at 07:56