Re: No knowledge of the database?

From: Costin Cozianu (c_cozianu_at_hotmail.com)
Date: 01/05/04 

Date: Mon, 05 Jan 2004 13:21:36 -0800

John Urberg wrote:

> "Costin Cozianu" wrote:
>
>>>>Such examples as
>>>>
>>>>http://www.c2.com/cgi/wiki?ManyToManyChallenge
>>>>http://www.c2.com/cgi/wiki?EjbTernaryRelationshipExample
>>>>http://www.c2.com/cgi/wiki?OrTernaryRelationshipExample
>>>>
>>>>make for a fun reading on the avatars of trying to apply OO ad-hockery
>>>>to funamentally relational problems.
>>>
>>>
>>>And they are meaningless examples comparing apples to oranges.
>>
>>It's no comparison at all. They are examples that show that bad object
>>designs have serious problems dealing with elementary things. And the
>>reason for that is that both language designes and frameowrk designers
>>haven't done their homework.
>
>
> I'm still trying to understand what's so bad about the domain model I
> presented. If you remove all the implementation details, you get the
> following:
>
> public interface Part {
> String getPartCode();
> }
>
> public interface Supplier {
> String getName();
> Set getParts();
> }
>
> public interface Project {
> String getName();
> Set getRequiredParts();
> Collection getSuppliersFor(Part part);
> Collection getPartsSuppliedBy(Supplier supplier);
> }
>
> I would think the conceptual data model for your relational model looks
> quite similar to the class diagram for this code. Assuming there is
> substantial code that needs to be written to this model, why is it a bad
> thing to use the same model in code?
>
>

Did you miss the fact that you introduced an unnecessary entity in order
to be able to cope with a ternary relationship ?

Next challenge if you want, I'll give you a 5-ary relationship to model,
again a very practical example not something stretched out. Maybe you'll
then realize that there's something fishy about the usual OO approach to
relationship (aka associations).

>>>Your
>>>challenges all stop short once the data gets into memory and provides
>>>little guidance on what to do next other than "get the damn data on
>>>the screen".
>>
>>What's wrong with putting data on the screen?
>>
>>Any experienced developer knows that putting data on the screen and
>>other simple transformation, and doing it smartly is roughly 80% of
>>business applications.
>>
>>That's for example, what amazon shopping, yahoo shopping, ebay, my
>>online banking system are supposed to do most of the time, the
>>transactions with very complex business rules are not pervasive in
>>business systems if for no other reasons than for having the business
>>rules that are manageable and comprehensible by the human beings that
>>decide them, and for the human beings that are impacted by them.
>
>
> Your experiences are quite different from mine. Getting the data on the
> screen is the smallest part of the work. It's been pretty standard for me
> to have to implement hundreds of business rules on just a single screen.

You mean like data validation rules ? Oh, well. You surely don't need
objects for that.

Other than that you must be working in a very peculiar domain to have
hundreds iof validation rules on a single screen.

How are your users able to cope with that complexity ?

> The seemingly simple domain I'm working in now has an ever expanding
> number of customizations that make each screen quite complex.

The fact that the screen are complex, is surely a problem of the GUI
code and not a problem of the underlying data, or the underlying object
model.

> We are also
> adding n-tier distribution and are incrementally rewriting the system with
> the plan to redesign the database once the rewrite is complete.

I really don'tt understand how you are mixing orthogonal concerns.
Surely how you access data has nothing to do with 3 tiers versus 10-tiers.

Redesigning the database isn't something very commendable, either.

> "just put
> the damn data on the screen" has proven to be woefully inadequate in my
> work.
>

Well, have you considered that you didn't do it right ?

That it more or less works even for very demanding projects is
established by many successful or just good enough projects.

On the other hand there are lots of object model centered projects that
have failed.

>
>>>They are meaningless challenges without substantial
>>>behavior that needs to be implemented on the data.
>>>
>>
>>They are simple challenges, but not meaningless challenges. A good
>>approach ought to make complicated things simpler while letting simple
>>things be simple.
>>
>>I am justifiably doubtful that an approach that fails to deal with
>>simple things in a simple and straightforward manner, can provide
>>significant help with complicated things.
>
>
> Here's one of your challenges: "For some particular projects the project
> manager can decide that only those suppliers can qualify that can offer
> all the parts needed for that project. Therefore we need a screen where
> the project manager can see which suppliers qualify." That is a problem
> that is handled by a single query. There's no behaviour beyond that.

Right, but if you don't take the "put the damn data on the damn screen"
approach for this particular screen and you want to climb your object
model, or "object oriented view of data" like some people ignorantly
claim it, you might be in for some trouble.

> There's no need to involve objects in that at all. It's about as
> meaningful as a challange for the RDBMS solution to a real-time embedded
> system problem. My mistake was assuming there was an understanding that
> there was more to the system beyond that, which would merit an OO design.
> Since there wasn't, my solution would then be to fire up my report
> builder, enter the query and format the results.
>

Oh, but why do you think you needed a report builder for that ? You
don't even need a report builder.

Now having established that an "object oriented view of data" doesn't
cover some places, do you agree then that parts of some projects are not
centered around the object model ?

Furthermore if the paradigm someone uses -- such as EJB, as well as the
OO brainwashing that some developers suffer from, will insulate the
developer from having anything to do with knowledge of database schema
and of SQL, then they are in for trouble.

> Regards,
> John Urberg
>
>

Best,
Costin

Relevant Pages

  • Re: No knowledge of the database?
    ... >> And they are meaningless examples comparing apples to oranges. ... > designs have serious problems dealing with elementary things. ... Collection getPartsSuppliedBy(Supplier supplier); ... > business applications. ...
    (comp.object)
  • Re: The Customer is Always Right -- Revisited
    ... The reason you have someone sign off on the business rules is ... > customer is always right lately. ... > not gotten the business rules correct and the designs he had signed off on ...
    (borland.public.delphi.non-technical)
  • Re: How inaccurate is a 555 or 7555 REALLY?
    ... The reason I don't want to go slogging through your stuff is because ... And we didn't need two detectors - a sing;e relatively fast ... designs, since if you had been ... That isn't exactly genius. ...
    (sci.electronics.design)
  • Re: snow in... NEW ORLEANS!
    ... control designer and had a 10 year small business doing custom designs. ... are you the John Larkin from Fullerton? ... Do you know of TANO Corp, ...
    (sci.electronics.design)
  • Re: snow in... NEW ORLEANS!
    ... control designer and had a 10 year small business doing custom designs. ... are you the John Larkin from Fullerton? ... Do you know of TANO Corp, ...
    (sci.electronics.design)