Re: Need help to understand difference, and contrast between Relational database model and the Object-Oriented model

"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:e4330f45.0312100321.119aa1c0_at_posting.google.com...
> "Corey Brown" <corey_at_spectrumsoftware.net> wrote in message
news:<8FlBb.6497
>
> > > > Relational databases use keys. Object databases use some sort of
> > > > pointer to physical storage location.
> > > >
> > > > That's all.
> > > >
> > >
> > > Is this a nonsense competition?
> >
> > Alfredo, why don't you explain to us why you think this answer is
> > nonsense.
>
> Because it is evident for anybody with a grasp on data management.

    This is exactly the type of answer that I would expect from somebody     like Bob B. Why must you guys always answer direct questions with     inappropriate remarks like this. If you have the knowledge and the     ability to express that knowledge to others, why don't you take a     few minutes out to lay down some cold hard facts, instead of just     telling us to go educate ourselves? Why can't you step up to the     role of teacher and start explaining why you "think" one technology     is better than another?

>
> > I am also pretty sure
> > that ODBM
> > systems do use direct pointers to relate objects together.
>
> And I am pretty sure that SQL DBMSes use pointers internally.

    So your point about network databases being obsolete and discredited     doesn't count here? If using internal pointers is so foul, why doesn't it

    apply to your last statement? I know, I know go educate yourself.

>
> > Yes object databases are relatives of "Network Model" databases,
but
> > so what!
>
> So they are based in a primitive obsolete and discredited approach.
> That's all.

    So what! There are many many examples of technologies that have     been eclipsed by better designs. It doesn't mean that the     early designs are not practical or useful anymore.

>
> > There are certain types of applications that can benefit from
> > the
> > use of object database systems.
>
> Perhaps in very special circumstances when the flaws of the current
> SQL DBMSes are more important than the network model inherent flaws,
> and the flaws of the concrete OODBMS implementations.

    I don't think the circumstances are all that special. And I certainly hope

    that application architects are looking at more than just the flaws associated

    with specific db technologies, instead of looking at the overall picture of how

    and where a particular db technology is going to be used.

>
> But you need a good knowledge on the fundamental to decide when to use
> one tool or other appropiately, and the kind of nonsenses we can read
> here don't help.

    Please see my comment above. It doesn't do anybody any good if you're     just going to keep telling people how "misinformed" they are. Step up to     the plate and start transfering your knowledge to the people in the trenches.

>
> > Personally I use all the tools at my
> > disposal
> > when architecting a solution for a particular problem.
>
> Me too, but I try to base my decisions on accurate information.

    Ok, but certainly you're not basing your decisions purely on the theoretical

    disadvantages of an ODBMS over an RDBMS. The whole picture of     how the application will be used, how much data will be stored, how it     will be retrieved, the complexity of the data relationships and the environment that

    the application must work in must also be taken into account.

    My own automobile is theoretically and practically inferior to a new hybrid

    vehicle, but does that mean I have to stop using my car today just because

    better technology is available?

    I firmly believe that both ODBMS and RDBMS technologies have areas in which

    each may excel over the other. Choose the right tool for the job, don't choose the tool

    and then force fit it into a particular job. I worked for Bell Laboratories for over 18

    years, so believe me when I tell you that I have seen more than my fair share of applications

    where the technology was decided on before the requirements were analyzed, with the

    end result being a miserable failure.

    Cheers
    --Corey

>
>
> Regards
> Alfredo
Received on Wed Dec 10 2003 - 20:04:46 CET