 <p>If you're talking about large volumes of data (millions of rows+), then you will get have a benefit from using different tables to store them in. </p> <p>e.g. basic example 50 million log entries, assuming 5 different "types" of log table Better to have 5 x 10 million row tables than 1 x 50 million row table </p> <ul> <li><p>INSERT performance will be better with individual tables - indexes on each table will be smaller and so quicker/easier to be updated/maintained as part of the insert operation</p></li> <li><p>READ performance will be better with individual tables - less data to query, smaller indexes to traverse. Also, sounds like you'd need to store an extra column to identify what type of Log entry a record is (Product, Shipping....)</p></li> <li>MAINTENANCE on smaller tables is less painful (statistics, index defragging/rebuilding etc)</li> </ul> <p>Essentially, this is about partitioning data. From SQL 2005 onwards, it has built in support for partitioning (see <a href="http://msdn.microsoft.com/en-us/library/ms345146(SQL.90).aspx" rel="nofollow noreferrer">here</a>) but you need Enterprise Edition for that, which basically allows you to partition data in one table to improve performance (e.g. you'd have your one Log table, and then define how the data within it is partitioned)</p> <p>I listened to an interview with one of the eBay architects recently, who stressed the importance of partitioning when needing performance and scalability and I strongly agree based on my experiences.</p>