Re: Dreaming About Redesigning SQL

"Lauri Pietarinen" <lauri(dot)pietarinen(at)atbusiness(dot)com> wrote in message
news:bnhk4n$i3t$1(at)nyytiset(dot)pp(dot)htv(dot)fi(dot)(dot)(dot)
>
> Anthony W. Youngman wrote:
>
> >In article <bn72o3$as$1(at)nyytiset(dot)pp(dot)htv(dot)fi>, Lauri Pietarinen <lauri.pie
> >tarinen(at)atbusiness(dot)com> writes
> >
> >>Anthony W. Youngman wrote:
> >>>In article <bn4cca$dj0$1(at)nyytiset(dot)pp(dot)htv(dot)fi>, Lauri Pietarinen
> >>><lauri(dot)pietarinen(at)atbusiness(dot)com> writes
> >>>
> >>>>Anthony W. Youngman wrote:
> >>>
> >>>If we're indexed on order
> >>>detail. If Hammer appears in N invoices, then T = (1+N) * ST * 1.05 for
> >>>hammers, and the same for all the other products.
> >>>
> >>>Theory favours us, in that if a product appears X times in one invoice,
> >>>that's one read for us and X for you, but hardware will probably help
> >>>you more than us (that is, assuming thrashing cuts in) in that you
stand
> >>>a marginally higher chance of getting multiple instances of a product
in
> >>>any given read.
> >>>
> >>>
> >>>
> >>So for each product you get T = (1+N) * ST * 1.05.
> >>
> >>Now, for our SQL-DBMS, presuming that we build indexes for detail and
> >>product:
> >>
> >>order_detail(product_id, qty, unit_price) = 20 bytes/row
> >>product(product_id, product_name) = 50 bytes/row
> >>
> >>With 2 disk reads I would get
> >>8K/20 = 400 order detail rows and
> >>8K/50 = 160 product rows
> >>
> >>Since all rows are in product_id order, no need for random disk reads so
> >>T = 1 + N/400 + P/160 (N=number of details, P=number of products)
> >>for ALL products and details.
> >>
> >>And, because of sequential prefetch, we probably would not have to wait
> >>for I/O's at all.
> >>
> >>Really, however you calculate it, it is an order of magnitude less
> >>than your alternative.
> >>
> >>And please don't tell me that using indexes is not fair or not in the
> >>spirit of the
> >>relational model ;-)
> >>
> >>
> >
> >Well, it does result in data being stored multiple times ;-)
> >
> What on earth is wrong with that? Do you know how much 160GB of disk
> cost's today?

Lauri,

Remember who you are talking to. Wol is ignorant and stupid. Somehow he
thinks managed redundancy at the physical level is non-relational because
normalization seeks to reduce redundancy at the logical level.

You have to keep in mind that the man is totally incompetent to comprehend
simple english let alone basic principles of data management.

Regards,
Bob