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

On 13 May 2003 20:55:30 -0700, wizofoz2k_at_yahoo.com.au (Nuno Souto) wrote:

>I have a Java "system architect" on record saying that relational
>databases are useless for OOD because they don't allow him
>to build relationships on the fly as needed! He'd much rather
>have a flat file and build "his own" relationships.
>
>Is that loopy or what? I mean, if there is ONE FUNDAMENTAL
>reason for the use of relational it's PRECISELY because it
>lets one build relationships as needed. It's the whole FOUNDATION
>of the darn thing!!!

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

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

What this table means <COUGH> is that Jones is piloting flight 133 (because he's in the left chair of seat 0); he has a blue security badge. Smith is the copilot (right chair of seat 0). Rubble and Flintstone are passengers in 31A and 31B. Rubble has red hair, and Flintstone has brown hair.

[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.]

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. (You could generate this view from 5NF tables. It would be stupid, IMHO, to put security badges and hair color in the same column, but I could probably do it if I had to.) But I suspect that they believe database designers just take too long to build tables. (That is, that we take too long to understand what the data means and how it fits together.)

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.

-- 
Mike Sherrill
Information Management Systems