Re: Relational-to-OOP Tax


Patrick May wrote:
"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.

Well, either way, you have not presented evidence of the DB getting in
the way for typical biz apps; simple, CRUD, or complex. There is no
"getting in the way" evidence so far.



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.

I have no idea how you are measuring "complex". CRUD screens can often
be complex because the rules for what, when, how, and where to display
stuff can be sticky and involve a lot of nitty gritty biz rules. If
CRUD was truly simple, then it would be packaged in easy libraries or
tools such that they could be wipped out in half-a-day. However, good
interface design is often difficult and requires trial and error, and
lots of nitty gritty rules and exceptions to the rules if you want to
give the customer a good product. Getting something up and running can
be done fairly easy with RAD tools, but often the results are not very
effective. It is sometimes said that RAD tool make the first 80% of
the job a snap, but the last 20% nearly impossible. They get you
"almost there" fast, but then bog you down.

Give an example of this unicorn that busts DB's or I will lump it with
bigfoot on the Existence Scale.


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.

Freeb already gave one. Wrapping is objectively more code for single-
use SQL than in-line. And similarly, an IF or case statement connected
to a database attribute is objectively less code than a single-use
polymorphic dispatch on the same attribute.


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.

No, I am arguing it is irrelavent to OO versus relational. If you want
to argue for Functional or Prolog-logic, go for it, but not here.


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

Having more *by itself* does not automatically improve it, you would
probably agree. As far as whether it *can* improve it if done right,
it is hard to say. It cost brain power and training to switch back and
forth between paradigms and changing code from one paradigm to another
is costly when domain requirements take away a given paradigm's
advantage for a given spot of code. There is probably a point of
diminishing returns such that the skill to know and read multiple
paradigms becomes more of a drag than having more options adds. If
programmers lived 500 years and were not pressured to leave the
profession after 42, the situation might be different.

My concern is whether heavy use of OO noticably and objective improves
biz apps. I've seen no evidence of such.


Sincerely,

Patrick


-T-

.

Relevant Pages

  • Re: Nikon FDUtility
    ... At the most absolute extreme (relational databases) each data item ... It is indeed comparable to database design. ... and then tries to fit a concept within this paradigm. ...
    (comp.periphs.scanners)
  • C# programmer looking for a job
    ... Software Development including Desktop, Client/Server and Database ... Practical skills in object oriented design and design patterns ... XML, Oracle, CVS, VSS, Delphi, bug tracking. ... Developed in Delphi5; ...
    (misc.immigration.usa)
  • Re: O/R Mapper
    ... | - create E/R model from niam model ... classes that contain, not only data, but also functionality as OO design is ... a database where they do not exist in the object model is corrupting the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Relational database & OO
    ... can be applied beyond the RDB's table/tuple paradigm. ... relationships in an RDB represent a specific implementation of the ... But no existing production database qualify as a relational database. ... Neither do the relational model or SQL. ...
    (comp.object)
  • Re: Date range on reports
    ... > box to your report with a control source like: ... >> In the Database window (Database window: The window that appears when you ... >> In the New Form dialog box, click Design View, and click OK. ... >> Begin by clicking Macro Names to display the Macro Name column. ...
    (microsoft.public.access.reports)