Re: Database development
On 27 Apr., 02:31, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
On 26-04-2010 16:14, Robert Klemme wrote:
On 04/26/2010 02:14 AM, Arne Vajh=F8j wrote:
I don't think the big benefits of ORM (Hibernate or JPA or one of the
alternatives) are in the writing of the code. It still requires
somebody that knows both the ORM framework and the database well
to write really efficient code.
The big benefits are for reading the code. Everyone can read the
the code using ORM and immediately understand what it does without
looking at tons of code that uses JDBC and SQL. It is maintenance
friendly.
So you are saying that I need skilled people to write the initial code
and can give maintenance to less skilled people because the ORM using
code is easy to read? I am not sure that is a good strategy. Over time
software tends to decay because more and more bug fixes are applied and
features added. If only the people knew internals of ORM that wrote the
initial code I see a good chance that maintainers wreck havoc on the
performance and potentially the whole application if they change /
extend the easy readable code without knowing the tool they are using.
Even a change as seemingly simple as that of a field type from "int" to
"String" might have dramatic consequences. And just think of the woes o=
f
schema migration: if you have an installed base you urgently need
someone who understands the DB underneath and the ORM tool to come up
with a feasible migration strategy that.
Not quite. I am saying that you may want people that have a clue
about persistence to write and modify the persistence code, but
that developers that does not know about the used ORM framework
or the database will be able to easily read and understand the code
(while working on something else - like the business logic).
Thank you for the clarification!
Btw, did I mention that I believe database independence is a myth? :-)
It is a myth that is seen working everyday in the Java world, that
many Java apps using a good ORM (like Hibernate or one
of the JPA implementation) use the same Java code with different
databases. It is not always that easy. But for all the simple
stuff it works well.
Hm... The question is: how simple is "simple" and where does
"complicated" begin? Just an example, which I would rather place in
the "simple" bucket: assume you want to query for items that have a
field set to null. Considering that Oracle does not index NULL values
and another RDBMS that you want to use does so, you'll likely end up
with a clutch: either you use a different value for NULL which will
allow for uniform ORM code at the cost of a bad design; or you need to
make the ORM tool create different queries (and I do not mean the
difference between "VARCHAR2" and "VARCHAR") for Oracle and the other
RDBMS. You could, of course, also live with the FTS in Oracle but I
doubt you'll have much fun doing this on any reasonably large
database. :-)
In any case I believe the complicated stuff is where the fun begins -
so for _me_ DB independence is definitively a myth. ;-)
Kind regards
robert