> > I'm doing YADA work at the moment (Yet Another Database App),
> and I've run
> > into an old problem for which there never seems to be a really good
> > solution. This particular app is targetted at RDBMS Brand X
> (actually it's
> > Sybase), and now there is a need to retarget it to another RDBMS. I am
> > positive that more databases will creep into the story over
> time, so this is
> > the old database-independent-app problem.
> >
>
> I hear you!
>
> This is actually close to my speciality. I've been doing
> persistence middleware and object persistence especially for a
> lot of the last 15 years. My speciality is object persistence
> and especially through middleware I created. I just finished
> the grand opus of this work (unfortunately proprietary to my
> employer for now) in Java. The performance is quite good. The
> system includes in memory caching, multiple threading, its own
> lock manager and an adapter framework for plugging in different
> database products. It doesn't matter if they are even of the
> same type (all relational for instance). At the top the
> applications only see the middleware API. Also included is
> builtin support for binary relations, persistent collections and
> persistent queues. There is room in the architecture to scale
> and distribute the lock manager and cache and to support
> language adapters for different software language object and
> structure persistence. The system supports dynamically
> difining new object/structs whose instances can then be
> persisted, queried, related to other instances and so on.
I was going to mention object persistence as the solution to your
problem...always add another level of abstraction. Solves everything except
too many layers of abstraction.
One of my open source projects
(http://www.sourceforge.net/projects/dwengine/) includes a Java object
persistence layer that's fairly specific to certain types of data. It's in
the process of being implemented with various diffrent databases.
But anyhow, my point was going to be that a million solutions already exist
out there. The trick is using one of them from the get-go. Salvaging a
system in which one of those solutions wasn't used is always going to be
messy.
The day that someone comes up with a good general framework for upgrading
arbitrary legacy systems to, say, EJB, will be a good day. I'm not sure that
it's possible, however.
Reason
http://www.exratio.com/
This archive was generated by hypermail 2b30 : Sat May 11 2002 - 17:44:12 MDT