Mixing P/R philosophy with OO (within J2EE).

frebe wrote:
>> Customer X may only buy your product if it runs on top
>> of database A. They do not care what persistence framework
>> you use to be able to support database A, B, C and D without
>> changing the application code.
>
> The level of standardization in SQL is rather high. If you skip using
> stored procedures and use ANSI SQL 92, entry level, you can switch
> database rather painless.

Not true.

functions
locking
identity/sequences

>> In cases like that a persistence framework is a real benefit.
>
> If you only use a RDBMS for persistence, then it would obviously be
> very easy to switch, with or without frameworks, because you are only
> using 5% of the features.

It is not.

Arne

Thomas Gagne wrote:
> In my experience (24 years) I've never seen, visited, or consulted a
> company that changed its database vendor.

It do happen.

But not that frequently.

Arne

> >> Customer X may only buy your product if it runs on top
> >> of database A. They do not care what persistence framework
> >> you use to be able to support database A, B, C and D without
> >> changing the application code.
>
> > The level of standardization in SQL is rather high. If you skip using
> > stored procedures and use ANSI SQL 92, entry level, you can switch
> > database rather painless.
>
> Not true.
>
> functions

I already made an exception for stored procedures.

> locking

Do claim that different SQL databases implement locking so different
that it is not possible to write SQL statements that works for
different vendors?

> identity/sequences

Yes, som databases vendors handles sequences in a strange way, but it
is pretty easy to encapsulate the use of sequences in functions that
could be switched when the datababase vendor is switched.

The fact that there are some SQL statments that are different for
different vendors, doesn't mean that you have to put all SQL
statements into a separate switchable layer.

Do you have some more examples of differences in SQL syntax between
vendors? Your list is rather short and the issues you point out is
very easy to solve.

/Fredrik

> Hibernate is transparent persistence
> for the business objects. I want my application to be independent of
> the data source, since data can come from more places than the disk
> store.

A database and a disk store is two very different things. If you want
to create independence between these two, you can only use smallest
common denominator.

> So my business logic is not coupled to the RDBMS.

As much business logic as possible should be implemented using
predicate logic and set therory (relational algebra).

> Also,
> Hibernate is not 'practically a DB engine *itself*.' It is a tool that
> aids in letting my business objects be saved. It has none of the
> attributes of a DBMS at all.

It has a query language which is more or less a copy of SQL.

> Data outlasts applications.

Indeed. That is why we doesn't need to care so much about being able
to switch database.

> Databases and languages change seldom.

Languages changes more often.

> The domain model for the application may be different from
> that of the database,

Most programming languages only support domain models using the
network model. The relational model is much more powerful for
modelling your domain.

> Applications change often, business rules change even more often.
> Database change is slow and methodical and can be traumatic if not
> handled carefully.

As long as you don't break backward compatibility, changes in the
database schema may be very fast. Views may change very quickly.

> We do not want to put frequently changing logic
> into the DB, we want to put data into the DB.

We want to put as much business logic in the DB, as views, as
possible. Changing view is not traumatic.

> > > In cases like that a persistence framework is a real
> > > benefit.
>
> > If one more OO fan calls RDBMS "persistence" mechanisms, I will
> > personally bop them. File systems are "persistence mechanisms". RDBMS
> > are attribute managers, domain noun modelers, and they "encapsulate"
>
> The relational model is not the domain model.

What is wrong with set theory and predicate logic? Do you like pointer
better?

> It is a construct that is mapped to a domain model.
????

> It happens to be mathematically sound
> and very good at certain operations that conform to the underlying
> math,

An exellent reason why we should use it for implementing business
logic.

> and many of the implementations have done excellent jobs of
> efficient storage, security and management of the space.

They have done an excellent job of implementing business logic too.

> That is what
> they are good at. But don't tell me that the model as implemented in
> the DB is THE MODEL. In fact, I would argue that a good OO Domain
> Model is a better candidate for being THE MODEL than the relational
> model. It has less restriction and more flexibility to reflect the
> domain than the relational has.

Please give some examples.

> An RDBMS *is* a persistence mechanism.

Does the statement
select customerid, sum(amount) as total
from customers c join orders o on o.customerid=c.customerid
having total > 2000

have anything to do with persistence?

> It is
> a bad place to put application code and business logic. An OO program
> is a good place to put application code and business logic.

Some motivation please...

/Fredrik

>
> /Fredrik
>
> PS. Don't forget to use views as much as possible for writing business
> logic.
>

Can you please elaborate a little more here? What are the major benefits of
views (other than job security)?

-- EK

Arne, those questions were intended, I suppose, to anyone thinking they
have a requirement for DB neutrality. You brought up the difference
between creating a product or working on a project. I was just asking
questions to come to more specifics. Since this is Harry's thread and
not yours those questions are probably better directed at Harry, or
anyone else thinking vendor neutrality may be a design requirement.

--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

> Databases are used for persisting data. The other stuff is there
> to help doing that.

OO people uses databases for persisting data. The rest of us use it
for a lot of other things too.

/Fredrik

> > PS. Don't forget to use views as much as possible for writing business
> > logic.
>
> Can you please elaborate a little more here? What are the major benefits of
> views (other than job security)?

Views plays the same role as functions or methods in imperative
programming languages. They encapsulates logic that may be reused. For
example, lets say we are building a payroll application, we would have
tables (base relations) for data entered by the users, like in/out
punches, absence reports, etc. But as much as possible of the derivied
data, like net pay and tax, would be calculated using views.

/Fredrik

On Apr 4, 2:09 pm, "topmind" <topm...{}technologist.com> wrote:
> gryphon_smg wrote:
> > On Apr 3, 8:55 pm, "topmind" <topm...{}technologist.com> wrote:
> > > Arne Vajhøj wrote:
> > > > topmind wrote:
> > > > > Before we get into the politics of Java, there is something ironic
> > > > > about O/R wrappers like Hibernate: they are almost more complex than
> > > > > the RDBMS itself. Thus, one is wrapping the DB with something that is
> > > > > practically a DB engine *itself*. Is being married to Hibernate less
> > > > > of a sofware engineering change-flexibility "sin" than being married
> > > > > to Oracle or PostGreSQL? I never figured out the "logic" behind such.
>
> > Yes, it is much less of a sin. Since you are picking on Hibernate I
> > will use that as the example. Hibernate is transparent persistence
> > for the business objects.
>
> Again, if you are using the RDBMS as ONLY a dumb object dumping
> ground, then you may be right. However, many of us think it is a good
The RDBMS is not a dumb object dumping ground; it is a smart object
dumping ground. It has no 'further potential'. If you add to it, it
is then an RDBMS and procedural programming language.

> idea to use the RDBMS to its fuller potentially rather than reinvent
> database idioms in app code and build ugly navigational structures
What is being reinvented?

> with a bunch of set/get red-tape on top.
>
> > I want my application to be independent of
> > the data source, since data can come from more places than the disk
> > store.
>
> RDBMS are not about disks. SQL is an *interface*. Hiding from one
> interface (SQL) by using another (Hibernate) simply *trades* one
> dependency for another, NOT rids net dependencies.
Wrong! RDBMS's are all about disks. I want my application code to
completely isolated from the source. My business logic should work on
the domain model, and not be tied to the source of the data or how it
comes or goes. Then I can use the same logic throughout the
enterprise.

>
> > So my business logic is not coupled to the RDBMS. Also,
> > Hibernate is not 'practically a DB engine *itself*.' It is a tool that
> > aids in letting my business objects be saved. It has none of the
> > attributes of a DBMS at all.
>
> It is complicated middle-ware with some quasi-DB qualities.
Name the quasi-DB qualities.

>
>
>
> > > > > It appears to be hypocritical to me. I compare it to hiding behind
> > > > > Dracula to avoid being attacked by Frankenstein. Databases tend to
> > > > > outlast languages, or at least are switched at roughly the same
>
> > Data outlasts applications. Databases and languages change seldom.
>
> Then why the obsession with swapping?
>
> > The
> > whole point in using ORM is to make use of the data that is available
> > in a timely fashion without requiring a change or addition in the
> > database.
>
> Use of app-specific tables, views, and/or databases is not forbidden.
> If your DBA does not allow it, then that is an issue of internal
> politics. Using objects to create a mini app-specific RAM database is
> dumb in my opinion unless as a last resort. OO is crappy at managing
OO is phenomenally good at creating associations between objects. I
can include all of the FKR of the tables in on object and then treat
the assembly as a whole. That is the point of OO programming. ORM
does not imply a RAM database (although the 2nd level cache in
Hibernate is a huge boost). The DBS's primary concern is the
integrity of the data. If we are embedding application logic into the
database that can challenge that, then the DBA is correct in
forbidding it. It is not politics, it proper.

> bunches of links between objects, creating navigational spegghetti
> which is the Goto of the 2000's.
That sounds like a competence of implementation problem, not an issue
with the underlying model. Anyone can write bad code in any
language. For this discussion, I am assuming that the programmer is
capable writing quality code.


>
> > The domain model for the application may be different from
> > that of the database, so having an agile mapping system makes sense.
> > Applications change often, business rules change even more often.
> > Database change is slow and methodical and can be traumatic if not
> > handled carefully. We do not want to put frequently changing logic
> > into the DB, we want to put data into the DB.
>
> Queries and Views are another technique to map the shared data to app-
> specific or task-specific views.
But once again, they are tied to the database. My users are not
supposed to work on the database, and do not have the qualifications
to do so. We use views for filtering data sets and creating
alternative displays, but to create an order, a view is no better than
the query that defines it and is still not the natural way the the
users expect it. It is also easier to program against one object than
11 tables.

>
>
>
> > > > Customer X may only buy your product if it runs on top
> > > > of database A. They do not care what persistence framework
> > > > you use to be able to support database A, B, C and D without
> > > > changing the application code.
>
> > > Databases are far more than "persistence" if you use them to their
> > > potential. If you *only* treat it as a dumb filing system and do most
> > > of the collection-oriented handling by building complex data
> > > structures in app code, then you are reinventing the wheel. Many OO
> > > designs seem to do this. Complex data structures (such as objects
> > > pointing to objects) should not really be needed often if you use the
> > > DB right.
>
> > > Plus, you didn't answer the issue of trading marriage to a DB vendor
> > > into being married to Hibernate. If the language carries its own
> > > database engine (which is just about what hibernate is), then you
> > > might as well ship the product with a specific RDBMS, such as MySql or
> > > PostgreSQL to get a consistent DB engine.
>
> > In the case of Java (since that is the language we are talking about)
> > using a good DAO pattern, it is quite easy to switch the DB interface
> > layer. Much easier than switching DB's. But that argument is, IMO, a
> > red herring. I don't see DB switching as an issue. Because data is
> > such a huge company asset, the DBMS tends not to change. The real
> > benefit of ORM is that it allows easy use of relational-modeled data
> > in an OO language.
>
> If swapping vendors is not the issue, so then what exactly *is* the
> problem with using direct queries in the app?
It couples the application directly to database, it imposes the
relational structure of the data onto an OO language and it crosses
concerns.

>
>
>
> > > > In cases like that a persistence framework is a real
> > > > benefit.
>
> > > If one more OO fan calls RDBMS "persistence" mechanisms, I will
> > > personally bop them. File systems are "persistence mechanisms". RDBMS
> > > are attribute managers, domain noun modelers, and they "encapsulate"
>
> > The relational model is not the domain model. It is a construct that
> > is mapped to a domain model.
>
> Horsecrap. It is as much the domain model as a bunch of classes. This
> is paradigm bias. (I will agree that some forms of "behavior" are best
> at the app level, but this does not take away the general domain
> modeling ability since we usually want most behavior at the app
> level.)

Wrong. It is a rigid mathematical structure that we use to store
data. An orderitem is part of an order, not a FKR. The domain model
is a model of the enterprise we are trying to automate. It is not
amenable to the restrictions of set theory, normalization or
relational algebra. All of those are restrictions on the model to put
it into an RDBMS. Your 'bunch of classes' are types that reflect the
components that we are modeling (the database has a single type:
table) with the type of relationships the have in the real world (As
opposed to FKR in the database). So it is a much better representation
to the user of the business. The relational model is very good for
persistence modeling, but that is its intention. Once again, trying
to extend it is the 'Golden Hammer' problem.

>
> > It happens to be mathematically sound
> > and very good at certain operations that conform to the underlying
> > math, and many of the implementations have done excellent jobs of
> > efficient storage, security and management of the space. That is what
> > they are good at. But don't tell me that the model as implemented in
> > the DB is THE MODEL.
>
> Maybe 70% of it.
?? What does that mean?


>
> > In fact, I would argue that a good OO Domain
> > Model is a better candidate for being THE MODEL than the relational
> > model.
>
> Prove it. Show the code of it being better.
Consider the classic Orders example. As a relational model it has
tables for Orders, Addresses, Orderitems, Orderitemattributes,
Shipping, Payment, and Tracking. They are associated with each other
through a series of FKR's. To implement in Java, I design a set of
classes. The Instance of the classes has all of the information I need
for that order and none that does not relate to it. I can apply the
business rules to the object or can write methods on the object that
implement the rules. But in anycase, my object is complete. I do not
have to navigate any relationships, I do not get duplicate information
with my joins. Most importantly, I do not have collect and build my
model one piece at a time.

To populate the object using direct queries will multiple queries as I
navigate the FKR's and pulling the results out of the rows that I
retrieve. Once I have applied my business logic, I have to do the
same with the updates. Using Hibernate, I request the Order by its
id, Apply the logic, and save it.

Using an ORM is not free. You have have a good domain object model to
start with, and do the mappings and queries that they use; this
requires talent and dedication. But you do that once and from then on,
you can use it again and again and again. I use one set of domain
models across multiple applications, so I amortize the up front
effort. For a new application, having this saves me 30% of my time
and all of the database access code that I would have to write. It is
easier for new programmers to come up to speed with a consistent
model, and we no longer have SQL embedded willy-nilly through the code
base.

In summary: it is better because it is more flexible, easier to
understand (and hence maintain), and more modular. Game Set Match.
>
> > It has less restriction and more flexibility to reflect the
> > domain than the relational has.
>
> Prove it. I agree that the "big iron" view of RDBMS popularized by
> Oracle is sometimes restricting, but in a flexible organization it
> does not have to be. "We use OO because our DBA is stubburn and slow"
> is perhaps understandable, but is that the full justification?
No we use it because it is faster to develop and more flexible. It
allows our business analysts to try new ideas easier and as a bonus,
our DBA is pretty happy about it as well.


>
> > That does not mean that we throw the
> > relational model away, it means that it is another tool in our
> > developers' tool box that we use when appropriate.
>
> > An RDBMS *is* a persistence mechanism.
>
> Noooooo! Persistence is one of many aspects of a RDBMS. You OO'ers
> have an obsession with disks.
No we have an obsession with using the right tool for the right job.

>
> > It is a very good one. It is
> > a bad place to put application code and business logic. An OO program
> > is a good place to put application code and business logic. It is not
> > reinventing the wheel, it is using a tool for the purpose it is best
> > suited. In fact, doing it all in the DB is a case of the 'Golden
> > Hammer'.
>
> So OO is the Golden Hammer? I don't think so.
No, I don't either. I use the relational database for what it is good
for, an OO Language for what it is good for, an ORM tool for what it
is good for. The database is good for storing data in a
mathematically structured format. It is good at managing that store
reliably for a long time. It is not good at rapidly changing business
logic.

As an analogy, I once (a long time ago) worked with a man who was a
Fortran programmer. He wrote a compiler in Fortran, and tried to use
that as an argument that we did not need any other programming
language: Fortran could do it all. My response was (and it) just
because you can do something, doesn't mean you should. The same
applies to putting business logic into the DB. Sure, I can write my
business logic in stored procedures in the DB, but it is a bad place
to do so. It links business logic to data, and as stated earlier,
data stays, business logic changes often. It also ties your business
logic to the database platform. It forces you to implement you program
in a language that the DB vendor supports in the DB.

The biggest problem is that it pushes the design of the what ever
application you creating to look just like the database structure.
This is the case with things like Oracle forms, but also any tool that
tries to do code generation for CRUD based on the Relational Schema.

The Relational model is suited for efficient storage and retrieval of
table based data, but this model is not particularly natural for
people (especially non-programmers) to use. When I create an order
management application, the end user is interested in treating the
order as a whole, not one screen for customer billing, one for
customer shipping, one for each line item and another for shipping
information. I can write a Hibernate mapping that treats an order as
a single object, apply business logic to the order, not having to
follow FKR's to each part. Validate the object as whole and the
persist it to the underlying DBMS. Then, using a reporting tool, my
coworkers can do metrics and statistics on the same database.

Tomorrow, when my product manager comes to me and announces that we
have a new promotion to add to the business logic, I can implement the
new logic either in my Order object (not ideal) or in my rules engine
(much better), and deploy the change quickly with out affecting the
carefully designed and tuned database.

>
>
>
> > > common collection-oriented idioms into a semi-standard tool, rather
> > > than reinvent them from scratch like OO likes to do.
Please explain.


>
> > > > Arne
>
> -T-

On Apr 4, 10:14 pm, "frebe" <freb...{}> wrote:
> > Hibernate is transparent persistence
> > for the business objects. I want my application to be independent of
> > the data source, since data can come from more places than the disk
> > store.
>
> A database and a disk store is two very different things. If you want
> to create independence between these two, you can only use smallest
> common denominator.
>
> > So my business logic is not coupled to the RDBMS.
>
> As much business logic as possible should be implemented using
> predicate logic and set therory (relational algebra).
No, business logic should never be in the database. Data is
persistent, business logic changes frequently. We want to apply
business logic in the business application, not in the database. We
do, however want to express it in the predicate logic format; that is
what a rules engine is for. In fact, they are a much more appropriate
tool for them than stored procedures in your data base.

>
> > Also,
> > Hibernate is not 'practically a DB engine *itself*.' It is a tool that
> > aids in letting my business objects be saved. It has none of the
> > attributes of a DBMS at all.
>
> It has a query language which is more or less a copy of SQL.
So?
>
> > Data outlasts applications.
>
> Indeed. That is why we doesn't need to care so much about being able
> to switch database.
>
> > Databases and languages change seldom.
>
> Languages changes more often.
>
> > The domain model for the application may be different from
> > that of the database,
>
> Most programming languages only support domain models using the
> network model. The relational model is much more powerful for
> modelling your domain.
No, it is actually much less powerful. What it is is much more well
defined and formalized and predicatable. It is a good model for
managing relations and references, but that is all.

>
> > Applications change often, business rules change even more often.
> > Database change is slow and methodical and can be traumatic if not
> > handled carefully.
>
> As long as you don't break backward compatibility, changes in the
> database schema may be very fast. Views may change very quickly.
views are not data.

>
> > We do not want to put frequently changing logic
> > into the DB, we want to put data into the DB.
>
> We want to put as much business logic in the DB, as views, as
> possible. Changing view is not traumatic.
No, we want to keep all of the business logic in one, authoritative
place. Once you split responsibility, you are no longer sure which
implementation is correct (The man with one watch knows what time it
is, the man with two is never sure). Unless you database implements a
rules engine internally, no business logic should be in the database.

Never split responsibility.

>
> > > > In cases like that a persistence framework is a real
> > > > benefit.
>
> > > If one more OO fan calls RDBMS "persistence" mechanisms, I will
> > > personally bop them. File systems are "persistence mechanisms". RDBMS
> > > are attribute managers, domain noun modelers, and they "encapsulate"
>
> > The relational model is not the domain model.
>
> What is wrong with set theory and predicate logic? Do you like pointer
> better?
Actually, I like objects better, at least for programming. I like set
theory just fine. It works well for defining a relation model of my
business domain. It is rather poor for creating a general domain
model. It is very poor for expressing the world as the end users
understand it.

>
> > It is a construct that is mapped to a domain model.
>
> ????
>
> > It happens to be mathematically sound
> > and very good at certain operations that conform to the underlying
> > math,
>
> An exellent reason why we should use it for implementing business
> logic.
No, it is a excellent reason for putting our persistent data in
mathematically sound storage system. But that is all the database is.

>
> > and many of the implementations have done excellent jobs of
> > efficient storage, security and management of the space.
>
> They have done an excellent job of implementing business logic too.
They have done a very marginal job implementing business logic. And a
terrible job of quickly adjusting to new business requirement.
Remember the constraints in the relational model are relational
constraints, not business logic.

>
> > That is what
> > they are good at. But don't tell me that the model as implemented in
> > the DB is THE MODEL. In fact, I would argue that a good OO Domain
> > Model is a better candidate for being THE MODEL than the relational
> > model. It has less restriction and more flexibility to reflect the
> > domain than the relational has.
>
> Please give some examples.
>
> > An RDBMS *is* a persistence mechanism.
>
> Does the statement
> select customerid, sum(amount) as total
> from customers c join orders o on o.customerid=c.customerid
> having total > 2000
>
> have anything to do with persistence?
Only to the extent that it is meaninless without it.

>
> > It is
> > a bad place to put application code and business logic. An OO program
> > is a good place to put application code and business logic.
>
> Some motivation please...
See above. Summary: Use the right tool for the right job. Do not share
responsibility. Be agile.

>
> /Fredrik