Re: WWW/Internet 2009: 2nd CFP until 21 September

From: Walter Mitty <wamitty_at_verizon.net>
Date: Mon, 10 Aug 2009 19:04:47 GMT
Message-ID: <jb_fm.1432$nh2.645_at_nwrddc02.gnilink.net>


"paul c" <toledobythesea_at_oohay.ac> wrote in message news:ooZfm.38508$Db2.36932_at_edtnps83...

> Walter Mitty wrote:

>> "paul c" <toledobythesea_at_oohay.ac> wrote in message
>> news:vNXfm.38495$Db2.20491_at_edtnps83...
>>> Walter Mitty wrote:
>>>> ...
>>>> The relational view of data as regards data in transit over a network
>>>> extends the scope of discussion of the relational model beyond the
>>>> scope contemplated in 1970. The discussion in 1970 and for many years
>>>> afterwards focussed on the application of the relational model to the
>>>> organization of data banks for large scale sharing of data. Large
>>>> scale sharing of data is increasingly being carried out by shipping
>>>> data over the network from one system to another. Any databases
>>>> involved are in the background.
>>>> ...
>>> In the 1960's, let alone the 1970's, "large scale sharing of data" by
>>> people was already a given requirement, no matter whether the vehicle
>>> was hierarchies or graph designs. The more urgent problem, recognized
>>> even by the Codasyl people, was sharing of data by applications..
>>
>> First, I've always taken the word "user" in the 1970 paper to apply to an
>> application program, or to a fairly transparent command and print
>> utility, or to a human using the database as mediated by either an
>> application of a utility program. My reading might not have been careful
>> enough.
>>
>> Second, as to whether sharing was a given requirement or not, I'd have
>> to say that it depended on who you talked to. A large part of my career
>> from 1985 through 1999 consisted not only in enabling people to share
>> data, but in convincing people of the merits of doing so. In almost
>> every client company there was a large faction that stood to lose, or
>> thought so, if data sharing prevailed. Even today, I'd say that over
>> half of the databases being built in SQL server are planned for use only
>> by a single application inside which the database is to be embedded. ...
>
>
> No doubt, but I think Codd was emphasizing that even an individual 
> application becomes more clear to the user, or observer if you prefer, if 
> it uses his few simple universal manipulators.
>

You maight be right. Or you and I might each be over analyzing the 1970 paper. What's clear to me is there has been a steady stream of object oriented programmers who have come into c.d.t. over the last five years, and ask why we think the relational model has merit when, to them, it looks like a return to procedural programming of the 1970s.

In almost every one of those conversations, the OO person has stated or intimated that he's the only one who will have to understand his own code, and or the data structure of the data stored in the database. In some cases, I may be reading too much between the lines. In other cases, they've made it crystal clear that this is what they think.

Now it's a fact that people are born naive. If you look up the origin of the word "naive", it's almost by definition. It seems to be the case that most people are still quite naive when they enter the workforce, regardless of their level of education. What's shocking to me is the number of people with ten or more years of professional experience under their belt who remain almost completely naive.

>
> I think he would have said that political territory and not-invented-here 
> attiitudes don't change that advantage.
>
>

This reminds me of the years I used to teach database courses. Sooner or later, a little over halfway through the course, students would begin asking why there was so much politics around the databases back at their work site. I learned to answer them thus:

Knowledge is power. So said Francis Bacon. Data is like knowledge in this regard.
When a database is successful, data gets shared. When data gets shared, power gets shared. When power gets shared, that's politics!

> Any use of the data by other

>> applications, or even by general purpose report generators or OLAP
>> environments is to be done through the app's API.
>>
>> The fact that such a view is monstrously naive doesn't prevent it from
>> being the majority view. Add to that the marketing plan that says that
>> the client has no choice but to return to us for access to their own
>> data, and you have the road to hell, well paved.
>
> Speaking of apps being 'users', I remember an airline that invented an api 
> with fourteen verbs so that the flight control system could notify cargo 
> process control at various destinations.  Nobody thought to include a verb 
> that would handle the re-routing of a plane after it had taken off, eg., 
> because of bad weather at the destination.  The funny thing was that only 
> four smallish tables were involved and they were more or less duplicated 
> at each end of a flight.  It would have been simpler to send every insert, 
> delete or update of those tables to the destination computers, echo the 
> tables at both ends and let each applicatiion decide whether it should 
> ignore or reflect the message, eg., four tables and three message types. 
> Supplier said that couldn't be done!

I'm reminded of another thing fro my teaching days. I had an example I would use from a hypothetical airline reservation system where the transaction control didn't have ACID.
I would then show how it was impossible for such a system to prevent overbooking. At the end of the example, I would always tell students that lack of transaction control wasn't really the reason reservation systems overbooked.

Then, one time, I had a student who had worked on the original SAABRE, or one like it. He corrected me. He said they had spent months trying to figure out how to detect overbooking, until finally the marketing people had decided that overbooking was a feature, and not a bug! They had not used relational, or even CODASYL databases in their work. And they had rolled their own transaction control. Received on Mon Aug 10 2009 - 21:04:47 CEST

Original text of this message