Option 1:

You can vertically partition a table by splitting the structure of a table into multiple tables based on column. For instance, you can have a main table with all frequently accessed columns and a supplemental table with less frequently accessed columns, joined on a unique key (one to one). This produces more efficient queries since, usually, there will be more extents read into memory for each request since the width of each data row is smaller.

Option 2:

You can horizontally partition your tables by splitting them by some range of values, typically by date range. For instance, Sales_1QTR2003, Sales_2QTR2003. You will have to maintain these tables through some sort of archival process, and create views which translate and aggregate these tables for your stored procedures. For instance, you can create a view called vSales_All which UNIONs all the separate sales tables, a view called vSales_2003 which UNIONs all the 2003 Sales tables, and so on. I believe Enterprise Editions allows more advanced indexing on these partitioned views. Perhaps someone with more experience in the arena may elaborate. But for now, you can look in BOL for more details.

Cheers,

Jay