Re: I think that relational DBs are dead. See link to my article inside

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 10 Jul 2006 18:09:56 GMT
Message-ID: <UJwsg.8765$pu3.196660@ursa-nb00s0.nbnet.nb.ca>

Josip Almasi wrote:

> Bob Badour wrote:
>

>>
>> I can only conclude you lack intelligence, education or both. The 
>> reason RDBMS will remain for a long time is exactly the reason why 
>> OODBMS is going nowhere: the foundations upon which each is built. One 
>> is founded on modern mathematics and the other is founded on nothing 
>> much in particular.
>>
>>> WRT technical reasons... OK I'll give you an example.
>>> I do use RDBMS for storage but the way I use it I could use dBase too.
>>
>> Why do you do that? Are you braindead or something?

>
>
> I'm simply writing object oriented applications that need persistence,
> and as you seem to have noticed (since you claim that OO model is
> founded on nothing), RDBMS and ER model in general is obviously unfit
> for the purpose.

What can I say to that? You are an idiot. You are clearly ignorant of the most fundamental knowledge related to your professed field. You would do well to heed Mark Twain's sage advice about keeping one's mouth shut and letting everyone think one is an idiot instead of opening it and removing all doubt.

> Its a well know fact, here, have a look:
>
> http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch

It's a well-known fact that OO is an extremely low-level procedural computational model, and one can easily remove the impedance mismatch by replacing OO with a higher-level declarative computational model. Duh.

[irrelevant nonsense snipped]

>>> I don't need referential integrity or cascades, since OO model takes 
>>> care of it.
>>
>> Yeah, sure. Right.

>
> Oh but it does, object cannot have reference to a deleted object
> (referential integrity), simply setting a member to null prunes entire
> subtree (cascade delete), setting member value to anything else reflect
> this value to all referrer object (cascade update), etc, etc.

Uh, yean, sure. Right.

>>> This isn't production code, in fact I've never even tried it, as I 
>>> never needed it.
>>
>> I see. You won't need it until you need it. And then what?

>
> I suggest you rephrase your question to emphasize expected answer more
> clearly.
> Or why not just tell me, you _know_, right?

You claim to have replaced a significant amount of data management code. However, you have no proof nor even a test to suggest that you have. Yet, when you need the recovery code, you will absolutely need it to work 100% correctly the very first time.

You have replaced nothing you moron. Unfortunately, your poor victims won't realise that until it's too late to do anything. Presumably, you hope to have left before that happens.

>>> But my point is it gets much more simpler with OOP.
>>
>> Correction: Your ignorant assertion is it gets much more simpler with 
>> OOP. Any informed and reasonably intelligent person will think you are 
>> a nut just for saying it.

>
> Well thank you for your correction; I'm glad no informed and reasonably
> intelligent person have seen my writings yet.

With all due respect, you lack the competence to make that assumption.

>> Is it? And what is the foundation of these event models you imagine? 
>> How do they differ from triggered procedures?

>
> Errr... how about you take a course or two in OOP?

Why? I have been doing OOP for 19 years now. What the hell do you think some self-aggrandizing ignorant is going to teach me that I didn't already learn (an perhaps reject as nonsense) a decade ago? Received on Mon Jul 10 2006 - 13:09:56 CDT