Re: New trend in modern IT consultancy - use your relational database as flat file

Mike Sherrill <MSherrill_at_compuserve.com> wrote in message news:<vpoacv40c8spahe9pm7i6chkd1jc9kt08n_at_4ax.com>...

>
> A SQL database that stays close to the relational model does let you
> build relationships as they're needed. But letting you (a DBA) build
> relationships /as needed/ isn't quite the same thing as letting an OO
> programmer build relationships /on the fly/.

Woooa! Stop right there. A DBA does NOT have a need to build relationships at all. It's the designer's/analyst's job to do that! I don't buy the story of the ubber-DBA that knows all and does everything. We have to start moving away from that idea.

>
> Based on my reading of various database and OO programming newsgroups,
> /some/ OO programmers want to build "relationships" like this on the
> fly. (That is, they want to build tables like this at run time.)
>
> Flight Pilot Seat Chair Passenger Color
> --
> 133 Jones 0 Left <null> blue
> 133 Smith 0 Right <null> blue
> 133 Jones 31 A Rubble red
> 133 Jones 31 B Flintstone brown

This is completely wrong if it comes from a OO group, for example.
What they should be building is a OO model with MOL this struct appearance (forget the exact syntax):

dbflightobj{
  Flight bigdecimal;
  Pilot string;
  seats seatobj(); // array
};

and then:
seatobj{
  seatnumber bigdecimal;
  chairpos string;
  passengerobj();
}

and yet more:
passengerobj{
  name string;
  secbadge string;
}

This is where the OO mob should STOP. How to map the results of a relational query to this is what the db designer should do using the O-R stuff in the DB. And it is VERY easy to do in Oracle:

Object view and an object type mapped to JDBC and bingo, no need for the OO mob to disarticulate the query resultset into their object model.

But there is NO WAY the OO designer/programmer should be getting to the data in a format similar to what you described. It's totally redundant for them and serves no purpose whatsoever other than increase the amount of "fluff" in each net trip to the db server.

Note for example that for EVERY row the flight number is being sent. What the heck for? To-be-sure-to-be-sure?

This is a very good example why there is so much trouble between OO and relational: neither camp is doing an accurate job of stating their needs and what they want and can do. Result: misunderstandings galore.

>
> [It's not clear to me whether Rubble's hair was red when he booked the
> ticket, when he had his passport picture taken, when he had his
> driver's license taken, or when he showed up at the gate.]

Exactly. But where does the problem lie in this case? Data model? I think so.

>
> I can't yet explain why they think things like this must be done at
> run time. I do believe they think flat files are superior to views.

They think that way because we DB designers and coders are doing an absolutely miserable job of telling them what's available and can be done for them! Sorry to say this, but it's true. Lots of marketing spiel, but so far I've seen remarkably few real life examples of how to handle O-R mapping. Apart from the usual crap of "shopping carts" and other cretin examples.

I spend considerable amounts of time explaining to the Java mob I work with, all that I can do for them. Apart from the occasional bout of Sun/IBM-inspired "we must stay decoupled from the db maker", mostly they like what they see and are turning around to having all this O-R mapping done by the DB.

It makes sense and is a thousand orders of magnitude more efficient than doing it with "foreach" loops in Tapestry or Struts! Wanna change the design? Give me the new object and I'll have a new "relationship" feeding it with data in half an hour. Now, that bets ANYTHING they can do with WSAD or any other tool by a country mile. Give me JDeveloper and I'll even give them the library with the java object syntax to boot. All they have to do is import it and away they go. And with the XDK, I can even give the data to them as a DOM-tree! Now they LOVE that, I can assure you!

>
> In my own defense, I'll just point out that we (you and I, anyway)
> work with /shared/ databases. You can't rightly share data without
> sharing its meaning.

Absolutely. But I tend to think that meaning is part of the data modeller's and designer's job. Not the DBA job at all. Nor the Java coder's job eiher.

Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam Received on Sun May 18 2003 - 19:56:35 CDT