Re: Relationals vs. Objects Databases I

In article <6aojqd$mhs$1_at_pebble.ml.org>, Joel Garry <joelga_at_pebble.ml.org> 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!

-- 
Jeremy Rickard

(To email, change "SPAM" to "jbdr" in address.)