Stored Procedure or Bulk Statements

Question

The story is that I need to optimize my database access.

Now I need to retrieve related data from like 6 different tables. and I've summerized the people's advise in those points:

1. Using the same connection for different commands still pays a visit to the db with every command execution

2. Stored procedures are a good way to have more than select statement (without using joins) to select from more than one table and paying only a single visit to the database

3. The source of the real load on the database is the connection to it, not the quantity of the data (quantity still affects the performance but N connections is a bigger factor).

Now I want to have multiple SELECT statements and as advised and more the points above I think I should go with the Stored Procedure option. but I got the thought to use batch SELECT statements instead

Example: SELECT e FROM p; SELECT x,y,z FROM t; SELECT ....; SELECT ....; SELECT e FROM p; SELECT x,y,z FROM t; SELECT ....; SELECT ....;

Will this cause in a single trip to the database as the stored procedure or not ? and what do you think about my options ?

..Thanks for your time in advance :)

Answer 1

You haven't mentioned anything about indexes. Start there because 6 tables is not a lot to include in a select statement. Exclude unnecessary columns and filter rows as needed. View the execution plan and see what is costing the most (there are a lot of other things to look for. Start Here ) If the results you are returning are not related, you can run as separate queries in a stored procedure.

Run it through the Database Engine Tuning Advisor and let SQL Server earn the licensing fee.

Having a stored procedure return multiple queries may not be an ideal solution: Any SQL Server multiple-recordset stored procedure gotchas?

Try to manage user expectations on the amount of data to pull. I have users I've been beating over the head because they absolutely must have a single dataset that has over 200 fields. They swore performance would never be an issue; times change.

Answer 2

Will this cause in a single trip to the database as the stored procedure or not ? and what do you think about my options ?

To answer your question: the only difference is that you're transferring the whole query instead of just the stored proc name to the database server. Unless your query is a few MBs long or is executed a few thousand times per second, it shouldn't make any difference in terms of performance.

Answer 3

I looked at your other question.

It is reasonable to have both approaches.

In some applications, it is reasonable to have multiple connections, each pulling data in parallel (you can do this in ADO.NET using asyncronous methods) for display on a form or web page.

However, in your case, with your model, one has to ask what you are doing with the data? The model is fine. Writing a query joining all the tables is also fine. But on a one-to-many relationship, what are you expecting? Are you expecting to populate one parent and then a collection of children? At this point you've left the world of rows and columns and you have an object model. This is where things like Entity Framework or NHibernate or custom code come into play - translating your good database design into an object model which can be used well in the application.