title: SQL Server 2005 - Are there any major negative implications to returning multiple tables w/ stored procedures?
body: <p>I've run across multiple situations in the last few months where legacy sql SP's are returning a single table made up mostly of redundant information. </p>
  
  <p>Example:</p>
  
  <p>Select CustomerID, CustomerEmail, CustomerAddress, InventoryLineItem, ShipQty from ...</p>
  
  <p>Returns:</p>
  
  <pre><code>55 a@b.com 723 StreetName InvLineItem#1 45
  55 a@b.com 723 StreetName InvLineItem#2 42
  55 a@b.com 723 StreetName InvLineItem#3 1
  55 a@b.com 723 StreetName InvLineItem#4 5
  55 a@b.com 723 StreetName InvLineItem#5 200
  55 a@b.com 723 StreetName InvLineItem#6 7045
  </code></pre>
  
  <p>(first 3 fields never change)</p>
  
  <p>Since I'm the only developer on the project, I've started breaking this into two select statements. (I work on the receiving .NET code as well)</p>
  
  <p>select CustomerID, CustomerEmail, CustomerAddress from ....</p>
  
  <pre><code>Returns: 55 a@b.com 723 Streetname  &lt;-- 1 record
  </code></pre>
  
  <p>select InventoryLineItem, ShipQty from ....
  Returns: </p>
  
  <pre><code>LineItem#1 45
  LineItem#2 42
  LineItem#3 1
  </code></pre>
  
  <p>etc.</p>
  
  <p>Obviously the resulting Dataset in .NET is smaller, but it really bugs me to have sometimes 10 fields in a select statement that are always under all circumstances exactly the same. Some of the queries may even return 10's of thousands of records. </p>
  
  <p>I feel like I'm doing the right thing here, but then again I'm no SQL pro.</p>
  
  <p>Are there any reasons for me to avoid this practice?</p>
  
  <p>Thanks in advance for your time.</p>