What about to use SQL Server's data partitioning with indexes on 'Read' property and with approach @Stefan suggested? IMO this should work, but using this approach you should to take care about updating 'Read' of a large set of entities because of the index rebuilding (you easily can turn the index off before large update and turn it on after). More about data partitioning you can find here: http://www.databasejournal.com/features/mssql/article.php/3638236/Data-partitioning-in-SQL-Server-2005---Part-I.htm http://msdn.microsoft.com/en-us/library/ms345146%28SQL.90%29.aspx
On Aug 14, 3:39 pm, "[email protected]" <[email protected]> wrote: > In our domain model, we have a Message entity. Message entity is basic > class with a simple string property and a status bool property if the > message is "read" or not . The thing is we are expecting millions of > messages and we would like to archive "read" messages. > > So I thought I could make use of "entity-name" property to > distinguish messages and "read" messages into to two different tables > so that selecting unread messages will perform better. > > But I am not sure how to manage it exactly, because a message can be > transformed from read to unread if it is read. > > So what do you recommend, entity-name is the way to go? should I use > an interceptor to make unread messages read (thus returning a > different entity name if message is read from interceptor) Will this > move the row from one table to another ? > > What other strategies you use for "big" tables ? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
