InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 19 Jun 2013 11:08:05 GMT20http://www.sqlservercentral.com/Forums/Topic802957-49-1.aspxI agree that this seems like an effort in the wrong direction. Consolidating these tables, based on limited information, does not seem to be a good idea.Tue, 19 Jan 2010 09:33:47 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic802957-49-1.aspxMay I ask what is the rationale behind such a consolidation project?The most active/queried to-be-consolidated table represents less than 10% of total data volume... why would somebody add to this table ten times more data that is not normally needed?From the performance point-of-view this looks to me like creating a proble in a place where there are no problems; in short, if it's not broken - don't try to fix it :cool:Tue, 19 Jan 2010 08:34:11 GMTPaulB-TheOneAndOnlyhttp://www.sqlservercentral.com/Forums/Topic802957-49-1.aspxHi Experts,I have a very unique requirement and I need some advice on the best strategy to tackle it. I have 5 tables with a combined data of about 358 million rows (22GB). out of those 5 tables, 1 of them (2GB) is actively queried. I need to consolidate all 5 tables into one table that would be queried from time to time. Here is what I think should be done i.e. my ideas-Consolidate the other 4 (non queried table) first into one table-Move the 5th active table data to this new tableAre there better ways to achieve this? What about locking on the actively queried table when moving data? Would I really need to partition (date range) the 22GB data or indexes would do just fine for querying?Any suggestions from you experts would be greatly appreciated. ThanksWed, 14 Oct 2009 11:16:02 GMTsqlislife