Re: ORM or JDBC?
Michal Kleczek wrote:
Lew wrote:
That's not true. The "whole point" about relational databases is to NOT
reflect the domain structure, but to store data as tables of rows.
No. RDBMSes do not store data as tables of rows. They _present_ data as
tables of rows (or rather - relations and tuples). The "whole point" about
Sure.
relational databases is to introduce a "logical model" and abstract away
from "physical model".
Well, I agree with that but still stand by my picture. Both "whole points",
and why I put the expression in quotes, are far from the whole point. Both
are valid points from a programmer's toolbox of ontologies.
What's more - the "whole point" of designing a database schema is to capture
as much relevant information about the domain as possible - the single fact
that you give a name to a relation or specify a constraint means you
_reflect_ the domain structure and _implement_ business logic.
If that was not the case all database schemas would be equivalent (and EAV
would be the most used one).
Yes, you are right.
Prior
to the relational model databases did try to store domain models and it
led to problems, problems so widespread and fundamental that hardly anyone
remembers non-relational databases.
I've never heard hierarchical databases tried to store domain models. Could
you point me to some material backing this statement?
I was putting a touch of poetic license in there, and also I was thinking of
network-model databases. These tried to capture all the relevant
relationships directly, rather than in the ad hoc fashion of the (pure)
relational model.
But you are correct - all these representations whether object or data are
reflections of the domain model, essentially projections of an /n/-dimensional
model space to an /m/-dimensional data or object model, where /m < n/.
Poetically speaking, of course.
We're all six blind men examining the elephant here.
The relational model intentionally breaks the domain model structure into
normal forms of just data, internally devoid of semantics. The genius of
the relational model is that it separated the domain model from the data
model,
leaving the mapping between them to a separate layer, the business logic.
As a result, database models capture the data from the domain model, but
they don't reflect the domain model directly.
Of course they don't. Neither do class models of applications using a
database.
You are correct.
By design the relational model imposes on the business logic the
responsibility to map the data model to the domain model.
At least we agree that a data model and an (OO) application class model are
different and have to be mapped.
I agree with nearly all of what you're saying.
But the question of whether one or the other is _the_ domain model cannot be
answered - they are equal. Furthermore - every application accessing the
same database has _its own_ class model that is suited for _this_
application.
Indeed.
ORMs are supposed to help with that responsibility.
But they fail to do so because they require a class model and a database
model to too closely mirror each other and this contradicts their purpose.
They don't require that. This is what's not in "almost all". It's a bit
tedious to construct an example, but for the category of projects for which
JPA (I excoriate other ORMs) suits, it imposes no restraints on the data model
whatsoever, and the entity model is constrained by the semantic model and
somewhat by the data model, which transitively depends on the semantic model.
I don't know what you mean by "too closely", but I really cannot conceive of
a normal business-type project where JPA plays a role in deciding the object
or data models. On the contrary, those flow from normal design and
development processes, and JPA is an implementation tool to connect the two.
....
Sometimes you need to abstract away the schema. Would you design an ORM
tool with a particular schema in mind?
Would you design a relational schema with only one application in mind?
It depends :)
Why this question?
To show that it's a similar question, and that the answer is, "It depends."
Usually a relational schema for a larger project supports more than one
application, e.g., inventory and order fulfillment share data. The parts of
the system interact with the parts of the schema that they need, and the
schema serves all parts.
Likewise an ORM tool assumes a kind of meta-schema - the (appearance of) a
relational data store. It's as general for the intended use as it needs to
be, that is, it allows all kinds of things that fit its meta-schema. Just
like a relational database schema permits all kinds of things, not all known
at the beginning, if they fit.
Using JDBC on a per-project basis is designing an ORM tool for one particular
database schema. That tool is your data-access layer for that project.
Both are excellent questions, for their respective domains of discourse. They
are part of the design and implementation question list one must generate for
a project.
You make well-reasoned, empowering points.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg