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

> I do buy and, in fact, like most of his arguments on OO hype, noun-
> oriented class design issues, etc. However, in absence of real tools,
> API, (language support?) that encourage P/R style, you can't really do
> much, can you?

The short is answer is: Use the LAMP stack.

Table oriented programming is not about new fancy tools, it is more
about not jumping into the layered mapping madness. If your
programming language allows you to use SQL, you have an working
environment. Next step is to use a (pre-) compiler that acutally
supports SQL. If use are using Java, SQLJ is a suitable tool. If you
are using C and Oracle, Pro*C is the tool to use, etc. Stored
procedures are another option. The third step is to use a RAD-tools
for more automatic generation of user interfaces. I can agree that it
is a shortage of production-ready RAD tools and SQL pre-compilers, but
the do exists. And if you don't find any suitable tools, just embedd
SQL statements as strings in your code (wherever you need it). It is
far better than O/R mapping.

/Fredrik

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

> 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.

> 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.

/Fredrik

On Apr 4, 11:48 am, "frebe" <freb...{}> wrote:
> PS. Don't forget to use views as much as possible for writing business
> logic.

Wouldn't it become a 2-tier arch then? A side question: can you step
thru a stored procedure in a debugger provided by the rdbms shell? (Is
there such a thing even?)

> > PS. Don't forget to use views as much as possible for writing business
> > logic.
>
> Wouldn't it become a 2-tier arch then?

Yes and no. It is nothing wrong with a client calling the database
directly, but for some tasks, it is better if the client calls a
stored procedure or a service on the application server. The client
might call both a database and an application server. As a matter of
fact, the database is kind of an application server. Forcing all
client request to be proxied through a application server to the
database, is only stupid.

> A side question: can you step
> thru a stored procedure in a debugger provided by the rdbms shell? (Is
> there such a thing even?)

I don't know. I would guess that Oracle has such tools. Poor IDE
support didn't stop people from start using Java a decade ago. And it
doesn't stop people from using JavaScript now. Debuggers are a nice
thing to have, but the lack of debugger is not a show stopper.

/Fredrik

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.

It seems the vendors' documentation tends to "trick" one into using
their proprietary syntax and functions, downplaying the standard
approaches. I've found it hard to find documentation on writing vendor-
neutral SQL. (The ANSI documents are not very human-friendly and
require lots of coffee.)

>
> > 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.
>
> /Fredrik

-T-

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. I want my application to be independent of
the data source, since data can come from more places than the disk
store. 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 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. 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. 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.

> > > frequency as languages. Thus, vendor-swap math doesn't seem to favor
> > > it.
>
> > It does if you are in the product business as opposed to
> > the project business.
>
> > Because then the resistance to change database actually
> > favors tools that encapsulate the database specifics.
Absolutely

>
> > 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.

>
>
>
> > 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. 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. 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. 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. 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'.

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

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 thatis
> > > > 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
idea to use the RDBMS to its fuller potentially rather than reinvent
database idioms in app code and build ugly navigational structures
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.

> 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.

>
> > > > 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
bunches of links between objects, creating navigational spegghetti
which is the Goto of the 2000's.

> 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.

> > > 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?

> >
> > > 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.)

> 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.

> 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.

> 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?

> 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.

> 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.

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

-T-

topmind wrote:
> 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
> bunches of links between objects, creating navigational spegghetti
> which is the Goto of the 2000's.

This is exactly why the relational model supplanted the network model.

O-O "databases" were not very effective the first time they were proffered,
when they were called "network-model" databases.

--
Lew

Thomas Gagne 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.
>>> 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
>>> frequency as languages. Thus, vendor-swap math doesn't seem to favor
>>> it.
>> It does if you are in the product business as opposed to
>> the project business.
> How many databases are you planning to support?

????

I am not planning on supporting anything.

I am saying that the "you do not change database" arguments
validity depends on whether you are doing a product or a project.

> Have you considered
> creating some vendor-specific linkages to take advantage of features in
> each?

????

I am expecting the persistence framework used to do just that.

> Can your product be shipped with a DB engine? Does your product need to
> integrate with other of a customer's data?

Often using the customers database is a requirement for either data
sharing or operational reasons.

> What kind of throughput do you need? Are concessions made in either the
> DB model or the OO model so you can use OR wrappers? If your OO product
> didn't exist would the DB model be identical?

????

It should be rather obvious that is an O/R mapper is used
then an O/R mapper can be used.

> Is vendor independence a feature of your current product or a desired
> feature of your next one?

????

I am talking in general terms about O/R mappers like
Hibernate.

Arne

topmind 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.
>>> 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
>>> frequency as languages. Thus, vendor-swap math doesn't seem to favor
>>> it.
>> It does if you are in the product business as opposed to
>> the project business.
>>
>> Because then the resistance to change database actually
>> favors tools that encapsulate the database specifics.
>>
>> 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.

I disagree.

> 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.

Actually I did answer it. Try and read it again.

> 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.

Nonsense.

You are ignoring all data sharing and operational aspects.

>> 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"
> common collection-oriented idioms into a semi-standard tool, rather
> than reinvent them from scratch like OO likes to do.

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

Arne