Re: Relationals vs. Objects Databases I

In article <news-reply.6897.02869643_at_sundialservices.com>, Sundial Services <news-reply_at_sundialservices.com> wrote:
>In article <dqa7tSA7OP00Ew5q_at_jbdr.demon.co.uk> Jeremy Rickard <Jeremy_at_SPAM.demon.co.uk> writes:
>
>>>>I guess the people I work for are less demanding, or the databases I
>>>>design better suited to the purpose.
>>>
>>>No, you just ignored the requirement for embedding as part of your solution.
>>>Without that "little" caveat, your original statement that SQL is a good enough
>>>language made no sense. COBOL is an additional cost, layered product in
>>>most cases, not part of SQL.
 

>>Yes, well that assumption was certainly at the back of my mind
>>originally, whether stated or not.
 

>>>Fortunately, I've managed to avoid it for the most part since 1980. I
>>>mean, '57 Chevy's may be nice, but I wouldn't want to commute in one.
 

>>Not when I can ride a bicycle, you mean? <g>
 

>>As I suggested before, I think it comes down to the type of system
>>you're developing. I'm working on the population of a sizable data
>>warehouse at the moment. We use COBOL to embed our SQL. That's not a
>>big deal. There would be little benefit in moving to, say, C++ to embed
>>SQL in - the structure of the programs is so simple that I find it hard
>>to see how OO programming techniques could add value.
 

>>You are saying it is useful because you could write / use classes that
>>would eliminate the need for SQL altogether. That's your opinion, but
>>personally I suspect that OO programming will find its niche elsewhere.
 

>>Time will tell. I'm retiring from the thread now to lick my wounds!
>
>
>Hey, no one should get beaten up for participating in a news group.

I miss the good ol' days.

>
>The reality that a lot of people just don't grasp, until and if they encounter
>it for the first time, is that some data-processing applications deal daily
>with a hemorrhaging profusion of data and have less than twelve hours to
>process it all. And, whether you like to write in it or not, COBOL is
>frequently the very best(!) language for such purposes. And, gawd help us,
>there are things a System/390 can do that no other computer on the planet can
>do as well. It is "a COBOL machine" to its very original System/360 design.
>
>But one of the goals of data processing, and one of the wonderful things about
>it as a profession, is to find the best tool for the job -- knowing that there
>are an endless variety of jobs and tools. Frequently what defines "the best
>tool" is that the tool is the most _expressive one in a particular problem
>context. But sometimes what defines "the best tool" is "the by-gawd biggest
>freight-train that will have the highest probability of making it to the next
>station with all 16,300,555 carloads of coal intact within the five-and-a-half
>hours we have in the night-time batch schedule for it to get there or the
>stores can't open tomorrow so there!" :->
>
>There's room for both.

Well, I wish that were true. Unfortunately, there is only room for that which tickles stockholders fancy. A mature product tends to make a lot of money, but with no prospect of growth it is only a revenue stream. That is exciting neither to young hotshot programmers nor stockholders.

>
>The problem domain defines the tool and the appropriateness thereof. Not the
>other way around.

I wish that were true too. Unfortunately, the tool domain is skewed by the "market." The "market" does not reward the most appropriate, only the best "marketing." IBM once had the best marketing. Now Microsoft does. Neither has had the best tools for a long time (with the limited exception of IBM and the high-end, and even that is now becoming arguable).

>
>You got a sack of grain to get to your neighbor's farm, you use a car. You
>got a hundred thousand tons of grain to get from Saskatchewan to Vancouver,
>you use a train.
>

IBM seems to think you should use a train for both. Where OS/2 is one of those little kiddie-trains... :)

-- 
These opinions are my own and not necessarily those of Information Quest
jgarry@eiq.com                           http://www.informationquest.com
http://ourworld.compuserve.com/homepages/joel_garry
"See your DBA?"  I AM the @#%*& DBA!