Re: Relationals vs. Objects Databases I

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.

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.

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

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. Received on Thu Jan 29 1998 - 00:00:00 CST