Re: Relational-to-OOP Tax

"topmind" <topmind@xxxxxxxxxxxxxxxx> writes:
Patrick May wrote:
However, it logically follows that if you are using a
relational database, then designing the application close to
it rather than trying to wrap it away in OO classes and
conventions will simplify the design because one is not
translating from one paradigm to another.

If you're thinking of a CRUD system, then you're correct.
For any system with more complex behavior, you're going to need
to provide some support for that assertion. (I'm not holding my
breath.)

Show me typical complex behavior in a biz app that relational
chokes on.

Once again you've got it backward. You are the one making the
claim above. It is up to you to support it or retract it.

Above YOU implied that staying close to the DB was fine for "CRUD"
apps, but not for "more complex behavior".

No, I agreed that using a database for simple create, read,
update, and delete operations, all directly supported by
straightforward SQL, made sense. The same clear overlap does not
exist between complex business requirements and database
functionality.

You made the claim that using the database features will simplify
the design relative to using OO techniques, without restricting the
context of that claim. You therefore have the burden of proof to
support that claim in the context of behavior more complex than simple
CRUD.

You appear to be more interesting in playing word games than
interested in figuring out why people say such and such is good.

Accusing your opponent of your own faults is known as
projection. You do nothing but play word games, making bold claims,
squirming, and finally refusing to meet the demands of intellectual
integrity by either retracting or supporting your assertions.

Prove your claim regarding simplification or retract it.

I don't find your question coherent as stated. I
frequently use languages like Common Lisp and C++ that are
considered multiparadigm. Multiparadigm languages offer a great
deal more flexibility than more constrained languages like Java.
Solutions that are infeasible in a less flexible language become
the most elegant alternative when the appropriate constructs are
available.

Perhaps, but that is not realistic for staffing purposes, per
above.

I'm not sure what you're referring to "per above", but I
haven't had a huge amount of difficulty hiring developers
experienced in more than one set of techniques.

All this mixing paradigm stuff is irrelavent anyhow.

You are essentially arguing that ignorance is preferable to
knowledge. You are also ignoring the fact that "paradigms" are
somewhat arbitrary and not mutually exclusive.

Do you honestly believe that having fewer tools available leads
to higher quality software than having more tools?

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

Relevant Pages