Moving Target DB and Abstract Schema

Question

I apologize in advance for seeming clueless. My explanation is this: There is no money. I have inexperience staff. I've been away from building architectures too long to be specific. I can't buy a contractor. I need some advice.
We are converting many Access applications to Java/J2EE/AnyRerelationalDB The way we have planned to approach this is to divide the DBs into various classes, say Personnel records, Vehicles, ...so on). These DBs will be moving targets that will change as we are able to discover Access applications that add/change features to whatever class of DB we're working with at the moment.
My goal is to eliminate changing each and every App everytime some DB parameter changes (DBMS, changed attribute, ..., etc). I think EBJ/abstract schemas will let me to get a generic view of the DB and insulate the App from the very real possibility of changing DB parameters.
I need some help verifying this or pointing me in a better direction.
Thanks for your help,
Bob

Answer 1

I apologize in advance for seeming clueless. My
explanation is this: There is no money. I have
inexperience staff. I've been away from building
architectures too long to be specific. I can't buy a
contractor. I need some advice.
We are converting many Access applications to
Java/J2EE/AnyRerelationalDB The way we have planned
to approach this is to divide the DBs into various
classes, say Personnel records, Vehicles, ...so on).
These DBs will be moving targets that will change as
s we are able to discover Access applications that
add/change features to whatever class of DB we're
working with at the moment.My first advice is that the description of you team doesn't bode well for the success of the project described in the second.
Let me frame it in another context to illuminate how dubious this sounds:
I want to build house with curved glass walls, high vaulted ceilings perched on a steep hillside. There is no money. I have inexperienced staff. I've been away from building houses too long to be specific. I can't buy a contractor.
My goal is to eliminate changing each and every App
everytime some DB parameter changes (DBMS, changed
attribute, ..., etc). I think EBJ/abstract schemas
will let me to get a generic view of the DB and
insulate the App from the very real possibility of
changing DB parameters.If you use an EJB layer than supports XDoclet or other portable CMP, yes, it will do this. However, it's not a simple and it your table structure changes significantly, your EJB will not work autmatically. The fact of the matter is that EJB is pretty complex and requires a lot of esoteric knowledge. Many EBJ projects have failed or produced terrible results. If you don't have any very capable developer/designers and/or have no developers with solid EJB experience I would under no circustances attempt this. EBJ is often overkill anyway. The real point of EJB is to help with distributed computing, not to abstract away the DB schema.
I simple approach that many people overlook is to use stored procedures. Stored procedures create a layer of abstraction between your code and the DB such that the DB can change without changing the code.