Re[2]: DB?

Hi

I would proceed as follows (my 2c!):

Generalize the storage mechanism.

For instance, roughly:
class Storage
        save(some base class ref) {
                medium.save(ref)
        }
        retrieve(dito)
        ...
        StorageMedium medium
        /* for instance */
        StorageMedium cache
        ...
}

or templates could be used for the StorageMedium

class StorageMedium {
        save = 0
        retrieve = 0
        ...
}

an abstract base class.

class FileStorageMedium
        implements the above using files
}

class DatabaseStorageMedium
        connects to db etc
        implements the above using the db
}

I guess by now you have an idea of what I mean.

The database storage mechanism should pass through a local cache file
(XML). All changes are stored automatically to the local file first. 
Upon 'Save' or 'Commit', the Storage used is synchronized with the cache
file. This means that it isn't necessary to move away from the XML format.
The DatabaseStorageMedium class (or derived classes) will take care of the
mapping between the XML and the database schema, whichever it is.

If the storage medium is the local file system, the relevant part of the
cache is simply dumped to it. 

I think that the storage format should be and stay XML, at least locally.
Too many advantages could be lost. The database can be considered a
centralized store, essentially not important for the individual (he's got
his data locally stored), which can be used as a collection and exchange
point. Other applications, e.g. time keeping apps, could use the data.

With this approach the database can be kept at arm's length, i.e. MrProject
doesn't get married to a schema (bad as we all know), and it would be very
easy to have a single person version (using the FS, happy not to run a DB)
and a corporate version (with a DB), possibly hooking into an existent DB.

Moreover, there is still a format to exchange information. One can load a
plan from the DB and simply save it as a file (dump the cache), which can
be sent to another company. The latter would only to load the file (gets in
the cache) and dump it to their DB (different schema).

There is another advantage in using the cache & commit.    
An 'idle thread' could be given the task to keep memory and cache in synch
as a safety measure. By time stamping the changes (in the cache) one could
also implement an infinite undo/redo. 

These are only rough ideas, but I think there is some potential.

Ciao

-- 
Michele Ravani                  [email protected]
"Those who live hoping, die singing" My Gran