Re: Database development
On 04/26/2010 12:48 PM, Lew wrote:
junw2000@gmail.com says...
When I work on database development projects, I use JDBC and SQL. Many
people use hibernate/spring. Can somebody explain the pros and cons of
using JDBC and SQL vs using hibernate/spring on database
developments?
Pitch wrote:
I always believed that ORM systems are forcing you to write your own
business-rules layer apart from the persistence layer. That way
database access is kept simple and easy mantainable.
ORM doesn't force business rules into a separate layer and raw JDBC
calls don't force them into the same layer as persistence.
Exactly. I believe there is a fundamental dilemma that I haven't seen a
satisfying solution to: with a relational database and an object
oriented (or not) application which implements the business logic you
automatically have a distribution of business rules between several tiers.
If you manage to place all business consistency rules into the database
(which is often impossible because either of limitations of the DB or
complexity of the model) you leave very little for the application layer
(mostly presentation) so you might wonder why not directly implement all
the business logic in PL/SQL or T-SQL (just to name two well known
brands). Advantage is that you cannot break the model if you need to do
changes in the DB (this can happen for migration, repair or other one
off tasks).
If you place all the rules in the application consequently you would
have to even get rid of foreign keys. Downside is of course that you
now have zero consistency enforcement for the data model in the DB (e.g.
during all those tasks mentioned above) and you are only using 10% of a
potentially expensive installation (in the case of a commercial RDBMS).
In reality I have often seen a mix between the two approaches: some
consistency checking (FK, PK, CHECK constraints, triggers) is done in
the database and the "rest" of the business logic lives in the
application tier. This may actually be the worst approach: it's not
only that you don't have a single place where the business model is
consistently defined and enforced - that is merely a violation of some
form of purity rule (which _does_ have its advantages). But this might
also make people feel safe when they change the database while breaking
business rules that live elsewhere...
We probably should get rid of persistence altogether - maybe Alzheimer
DB or WORN is the future. :-)
Also, this multi-tier architecture allows for easier load-balancing,
architecture changes, integration with other systems, development..
Pitch, you can have multi tier with JDBC and ORM - you can even have
multi tier without persistence altogether.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/