RE: Working with tables, best method

W/regard to the complexity of pricing, yes, pricing can get _very_
complex. However, in many cases, it doesn't need to be. There are _many_
companies that don't have different prices per customer-class,
item-class, quantity ordered of item, quantity ordered of item(s) in
class, etc. Heck, I've seen really crazy pricing, and I've seen systems
that worked just fine w/a single price on the item table. Yes, sometimes
the only way to price is in an HLL, but sometimes a simple SQL is fine.

Yeah, but it returns it over and over! In fact, one of the things I
absolutely cannot stand about joins, especially in multi-tiered
environments, is that duplicate header information is sent ON EVERY
ROW!

Only if you select it. Look at my SQL again, you will get _nothing_ back
from the order header. It's got nothing to do with joins, it's all about
the selection of fields you make.

However, I think we've come far afield of where we started. I _agree_
with you that HLL IO is faster for one-off reads. My point was, and
continues to be, that many times (not _all_ times, but many times) where
you think you have lots of single row reads, you really have a
set-oriented process if you rethink the process.

-Walden