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
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
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,
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,
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 =