Re: dbdebunk 'Quote of Week' comment
From: David Cressey <david.cressey_at_earthlink.net>
Date: Sat, 27 Aug 2005 10:41:01 GMT
Message-ID: <1rXPe.2452$9i4.1861_at_newsread2.news.atl.earthlink.net>
> "But the query performance in fully normalized relational
> databases can be quite poor. For instance, to find the address
> of the user named Bob, these implementations may look up Bob
> in the USER table, find his "primary key" (the login name),
> and then search the ADDRESS table for that key. Although this
> appears to be a single operation to the user, in most
> implementations it requires a complex and time consuming
> search through the tables."
> Complex and time consuming; yeah right. Two indexed lookups.
>
>
Date: Sat, 27 Aug 2005 10:41:01 GMT
Message-ID: <1rXPe.2452$9i4.1861_at_newsread2.news.atl.earthlink.net>
"Marshall Spight" <marshall.spight_at_gmail.com> wrote in message
news:1125125782.004306.247470_at_g47g2000cwa.googlegroups.com...
> David Cressey wrote:
> > "Marshall Spight" <marshall.spight_at_gmail.com> wrote in message
> > news:1125117675.786528.79350_at_f14g2000cwb.googlegroups.com...
> > > dawn wrote:
> >
> > > > So, is this wikipedia entry correct?
> > >
> > > I didn't read the whole thing, but what I did read was crap.
> >
> > I didn't read the whole thing either, but the part I read sounded ok to
me.
> > What did you think was crap?
>
> "But the query performance in fully normalized relational
> databases can be quite poor. For instance, to find the address
> of the user named Bob, these implementations may look up Bob
> in the USER table, find his "primary key" (the login name),
> and then search the ADDRESS table for that key. Although this
> appears to be a single operation to the user, in most
> implementations it requires a complex and time consuming
> search through the tables."
>
> Complex and time consuming; yeah right. Two indexed lookups.
>
>
You are right. This is crap. Received on Sat Aug 27 2005 - 12:41:01 CEST