Re: Nested Relations / RVAs / NFNF

From: Marshall Spight <mspight_at_dnai.com>
Date: Wed, 27 Oct 2004 14:38:13 GMT
Message-ID: <opOfd.429576$mD.166518_at_attbi_s02>


"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:ad0olc.vhc.ln_at_mercury.downsfam.net...
>
> In the simple case, this could be automatic, based on the declaration of the
> foreign key. If a foreign key appears twice there'd have to be a way to
> avoid naming collissions.

Or a way to indicate which one(s) you wanted as join criteria.

> But actually this is quite smooth. If we allow these virtual tables to
> chain together, can we do this:
>
> Select customer.customer_name,
> SUM(customer.orders.order_total),
> SUM(customer.orders.orders_detail.extended_price)
> FROM customer
> WHERE customer.orders.orders_detail.item_id = 'GONKULATOR'
>
> Which out to give this report:
>
> Customer Name Total Orders Gonkulator Orders
> ============= ============= ==================
> John Smith $500.00 $175.00

Exactly!

So, on a related note, it's a little weird that we use integers as keys. Integers support e.g. addition, so we are allowed to add two keys together. This is nonsensical. Perhaps, if we want to have surrogate keys, something different from integers might be in order. That brings me to my 2a) idea, which is a datatype that only supports these operations, and none other

  1. make me a new one
  2. copy
  3. test two such values for equality

[this idea is not original with me.]

Do we need anything more for these to qualify as "values?"

Also, this datatype is quite useful for nested relations, because you don't get unintended collisions. So you can merge and split subsets of relations without danger.

Marshall Received on Wed Oct 27 2004 - 16:38:13 CEST

Original text of this message