[nhusers] Re: splitting big tables and entity-name feature

2009-08-17 Thread Stefan Steinegger
When you split, you need an insert and a delete instead of an update. Splitting also means that you have to query two table in some situations. You could consider a solution where you have a separate table to store just primary keys of unread messages. Then you don't have to move records around

[nhusers] Re: splitting big tables and entity-name feature

2009-08-17 Thread Markus Zywitza
Read Release It. History data should not only go to a different table, but to a different database server, if possible. So make a batch run that transfers all read messages older than x days to a different server and expose this data via an explicit GUI. -Markus 2009/8/14 ReverseBlade

[nhusers] Re: splitting big tables and entity-name feature

2009-08-17 Thread Stefan Steinegger
If you store references to unread messages, you don't need to read flag anymore. I know this is a special solution, it only works because you could assume that most of the messages have been read. I wouldn't use both solutions at the same time. This data partitioning stuff might also work well,

[nhusers] Re: splitting big tables and entity-name feature

2009-08-14 Thread Stefan Steinegger
Why not simply: IListstring result = session .CreateQuery(select m.Text from Message where m.Read = false and ...) .Liststring(); and session.Update(Message set m.Read = false where ...); You could also have a list of ids to know which messages need to be set to read. On 14 Aug., 14:39,

[nhusers] Re: splitting big tables and entity-name feature

2009-08-14 Thread ReverseBlade
If you have 50 million of records then this solution is not feasible imho, that's why I am trying to split it. On Aug 14, 4:34 pm, Stefan Steinegger stefan.steineg...@bluewin.ch wrote: Why not simply: IListstring result = session   .CreateQuery(select m.Text from Message where m.Read =