Re: Mixing OO and DB

From: topmind <topmind_at_technologist.com>
Date: Tue, 11 Mar 2008 08:27:42 -0700 (PDT)
Message-ID: <cb4c1a15-f864-4af4-8262-1fdacda2ef6e_at_u10g2000prn.googlegroups.com>


Robert Martin wrote:
> On 2008-03-09 01:02:47 -0600, Marshall <marshall.spight_at_gmail.com> said:
>
> > On Mar 8, 6:07 pm, Robert Martin <uncle..._at_objectmentor.com> wrote:
> >> On 2008-03-06 15:37:56 -0600, topmind <topm..._at_technologist.com> said:
> >>
> >>>> Each small group of classes becomes a little roll-your-own data access
> >>>> and manipulation scheme that is perfectly tuned for it's very specific
> >>>> purpose.
> >>
> >>> Which is over-kill for the task-level.
> >>
> >> Do you have proof that it's overkill? Do you have any objective
> >> measurements that it's overkill? Or it is just your own opinion. I
> >> mean, if it works for you that's great, but don't force your own
> >> opinions on everyone else <grin>
> >
> > This is a fallacious argument. You're proposing extra effort without
> > justification. The idea that, in the absence of evidence either way,
> > topmind's proposal of not putting in that effort is on equal footing
> > with yours doesn't hold. Extra effort requires justification. What
> > you are saying is, "hey, we don't know if this work has any value
> > or not, so doing it is just as justified as not doing it."
>
> Go back to the root of the argument. You'll see that the initial
> premise is that the programmer organizes the data into a form that is
> more convenient for him to get his computational job done. So there
> *is* justification.

Depending on how "convenient" is measured.

Note that the effort to wrap SQL in methods is only one of the issues against it.

>
> >> It is very common for programmers to manipulate data into forms that
> >> are particularly convenient for the application they are writing.
> >> Databases are seldom in that form since (for one thing) they must
> >> usually serve many different and competing applications.
> >
> > (I'm going to just label the above as bogus without justification.
> > It's late and I'm lazy.)
>
> That's fine. Consider, for example, an algorithm that finds the
> minimum spanning distance of a graph. (e.g. cheapest network route, or
> cheapest travel itinerary, etc). The node and edges of the graph are
> stored in database tables.
>
> Shall we execute that algorithm by doing thousands of tiny queries as
> we walk from node to node through the edges? Or shall we query all the
> nodes and edges in one gulp, arrange them into a graph of objects, and
> walk through them that way?

I'd perhaps use a local temp table if the language supported it well (harkening back to my xBase days). OOP hype ruined such tools because everybody thought objects would replace nimble tables.

The dichotomy between formal DB "master" tables and local non-table structures is an industry flaw of habit or faddism. Local nimble work tables are a good thing and I miss them.

However, if local tables are not well-supported, the decision between querying the DB one/few nodes at a time and using local structures (maps, objects, lists, etc.) is "it depends". If the "nodes" are complex, it may make more sense to query the records as needed rather than make a local copy because we may not know in advance how to filter them enough to make a decent or small local structure.

(Also, like I mentioned earlier, existing query languages are not wellsuited  for most graph traversal, but it doesn't have to be that way.)

> >>>> That sentence is true. It is also true if you replace the phrase "the
> >>>> DB" with the word OO.
> >>
> >>> Show me how. I opened my wallet, purchased your book, and found it
> >>> wanting and produced a much simpler and flexible payroll example. For
> >>> free even. Unlike you, I don't charge for personal subjective
> >>> opinions.
> >>
> >> There's another one of those hidden emotional barbs. You realize of
> >> course that you have just promised that you will never write a book.
> >
> > Not at all. He could instead write a *factual* book.
>
> Ah, a book without opinions. Imagine writing a book on software design
> that had no opinions.

Or one that let the reader choose among multiple design trade-offs and perhaps talk about the pyschology of personal preferences. I'd try not to disquise psychology as universal rules. Hell, there may be alien races that are objectivelly better with Go To's. Frog People may naturally think in terms of jumping.

>
>
> --
> Robert C. Martin (Uncle Bob)��| email: unclebob_at_objectmentor.com
> Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com

-T- Received on Tue Mar 11 2008 - 16:27:42 CET

Original text of this message