Re: Relational-to-OOP Tax

"frebe" <frebe73@xxxxxxxxx> writes:
The retrieval, transformation, and use of data are conceptually
different; combining them in a single lexical unit reduces the
understandability of that unit.
[ . . . ]
In relational algebra retrieval, transformation and use of data is
not conceptually different. A single select statement can do it
all.

For some set of transformations and some set of uses, sure.

The messy code is caused by the fact that you insist to transform
relational data into object graphs. If you skip doing this you don't
have any conceptually different concepts.

You seem to be circling back to your still unsupported claim that
relations are the only necessary data structure, and adding the idea
that SQL is the only necessary language. Are you seriously claiming
that there is no need for other languages?

In what what way is

createEmployee(x,y,z)

function createEmployee(x,y,z) {
insert into employee values (x,y,z)
}

cleaner than

insert into employee values (x,y,z)

Even in this simple example, the name of the function is more
descriptive than the SQL statement.

Really? It is just different syntax.

Not at all. The function name describes what is being done, the
SQL statement describes how to do it.

It can also be re-used without exposing the database schema
throughout the application.

And the benefits with that are....?

Schemas change for different reasons than application code.
Coupling the application to the schema makes change more difficult and
risky.

I am not. Decoupling in a general sense have many benefits, but you
can't decouple everything from everything. Decoupling has also a
cost and that cost has to be compared to the benefits.

What are the exact costs you are so concerned with? The benefits
in terms of non-functional requirements alone are quite significant.
Even if the cost were always a small increase in lines of code, which
is not necessarily the case, it would seem to be well worth those
benefits.

Both horizontal and vertical scalability benefit from the existence
of decoupled, well-encapsulated components.

What is a well-encapsulated component in this case? Are you talking
about EJB beans or something here?

Goddess no. I consider EJBs to be the antithesis of a
well-encapsulated component. In this case I'm thinking of
fine-grained services that can be aggregated into coarser grained
services. Consider the case of an order management system that
consists of a workflow that accesses multiple applications (CRM,
billing, MRP/ERP, etc.). Each activity is a coarse grained service
that uses multiple, shared fine-grained services. Scalability can be
achieved both through distributing the services and by running
mulitple instances of any that are particularly heavily used.

Security is easier to implement and prove when components have
single responsibilities.

Do you have some examples of this?

One of the primary difficulties with implementing security
correctly is the difficult to understand interactions between
complex components. Having a single responsibility for each
component simplifies analysis and testing considerably.

Is this an example?

It's a description of the issue sufficient for anyone familiar
with implementing security models to understand my point. That makes
it far more supportive of my statement than anything you have yet
produced.

Now let's see your support for your claim that relations are the
only necessary data structure.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@xxxxxxx | (C++, Java, Common Lisp, Jini, middleware, SOA)
.