>
>
>
> Image as a database is my way of running my web apps for four years 
> already, and I make my living of them, so I can just agree and confirm 
> Ramon here!
>
> Janko
>
>

We have likewise used "image as a database" for bountifulbaby.com for years.

In the beginning we used PostgreSQL, but eventually yanked it.  We've 
never had a problem with just using the image.  However, we have a 
couple of other processes in place that help reduce the risk:

1. the production image is saved and a copy is brought over to the 
development system for all developmental coding updates.  This results 
in a production image save about 3 to 5 times per week.  The production 
image is saved into it's own separate archive area on the development 
system(s), so we can revert to the image that existed at virtually any 
point in time if we choose to, simply by grabbing any old production 
image that we wish to.

2. Several key domain objects use FileStream>>fileOutClass:andObject: to 
hierarchically write their contents to disk.  This literally spools out 
all of the important domain object's data to disk, where they can be 
read back in by any other production and/or development image.  This 
"save" snapshot happens automatically once a day, in the early hours of 
the morning.  Any image that reads this data back in from disk (via 
FileStream>>fileInObjectAndCode) will be restored to the state of the 
image at the time of the snapshot.

Consequently, if the production image ever hoses up, we at most risk the 
loss of a few hours data.  Furthermore, our normal order processing 
produces a paper trail from which we can manually update to restore even 
that, if we needed to.

But we've never needed to.

The "image as database" approach has been very reliable for us.  And a 
whole lot easier than any other approach.

Nevin