Hi,

My problem is one of application design.
I have some objects in my application which map to tables in database.
I used C# and mssql but that's not important.

The database is needed only for storing the results/objects at the end
of the program.
Another application will use the results stored in the database.

I have 2 choices: every time I create or edit an object, I can store it
in the database and then, the next time I need it, I can select it from
the database. The second choice is not to store any object in the
database until the end of the application, and keep all in memory.
My question is:
Which of the 2 choices is better?

Depending of the amount of input data, my objects can get very big so
if I use the objects, I will use a lot of memory.
The reverse, store the object in the database after I complete its
processing, and when needed, just select it from the database, is a lot
more time consuming.

doina babu wrote:
My first idea when reading this, is working with a cache-object. For
example if you are talking about images, it can be a good idea to have
an object that wraps around the image and you make get-set methods for
the image.
In the wrapper-object, you have an instance of the image. If the
instance is 'null', then it means the image is not in the memory, and
must be loaded if someone calls the get-method.
That way, only the images that the user needs are in the memory.
And you can store the images on a "set"-method (or use a timer to handle
the updating of the database).

Also, you can periodically look (with a timer) at the available memory,
and if that isn't sufficient anymore, you can throw away the image
itself by setting the cache to 'null'. The business-logic of the
application will not be harmed, because the image can still called by
using get (which will again load it from the database if the cache is
cleared).

Possibly, there are many more option, but this is the one that came into
my head first ;-)