So, yet another idea for a model for database access in applications. In ~traditional O/R mapping we tend to think of there being two things which are mapped to each other: the object model and the database schema. The "database schema" in this case is specifically the physical model. There is actually a third thing being mapped -- the logical model. In effect, with current o/r mappers we seem to come awfully close to matching the logical model in the object model. This makes sense -- the logical model is how we think about it a good object model is how we think about it. No wonder the two tend to be similar to each other.
In an ideal world you could have one model from which all else is generated -- orthogonal persistence from the perspective of the objects, tuples acting as substitutes for an interface in the object space from the perspective of the relational model.
How about we rewind database "technology" about thirty years and start talking about deriving the physical model from the logical model again -- and build the language-level (or library-level) constructs to correctly describe the logical model in the source -- then let the application derive a correct physical model from the logical model.
You can kind of do this now with an objects-first approach to modeling, but because object models do not enforce relational model constructs on themselves, you can blow it pretty easily. So, lets presume we are stuck with existing language constructs -- we cannot add the precise and accurate concepts of candidate keys and refvars to Java (or can we?), and types are definately Java types (or Ruby types, or C types, or Haskell types, whatever).
If you have rigorous developers you could map these in metadata -- objects-first/derived schema approaches used now do this to some degree. The current thought directions in the JDO2 expert group, and I am told in the persistence subset of the EJB3 expert group, leans towards keeping "mapping" metadata (columns, tables, keys, refvars, etc) at least conceptually seperate from "persistence" metadata (fetch groups, cascades, blah blah). How about we consider dropping the mapping stuff completely.
Every pragmatist reading this is shaking her head and saying "Brian's lost it and gone over to the dark side" -- but wait! Yes, there are legacy schema which need to be worked with. Heck, most new applications against new schema have legacy schema because we define the physical model before anything else (data first). But... this ain't the right way to do it, and maybe for new development we should consider doing things the right way. Ask the database vendors to support logical schema definitions and... integrate against the logical schema. Okay, yeah, I guess I am smoking crack. It's a nice idea, at least.
Something in this smells right, though, somewhere. I'm just not sure where.