Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Operationalize orthogonality

Re: Operationalize orthogonality

From: Marshall <marshall.spight_at_gmail.com>
Date: 4 Jun 2006 23:33:27 -0700
Message-ID: <1149489207.098512.218820@c74g2000cwc.googlegroups.com>


Tony D wrote:
> mAsterdam wrote:
> >
> > It is imperative for any practical solution (i.e. with indexing)
> > that ordering operators (<, >) of a type can be communicated.
>
> I think this needs to be handled on a type-by-type basis; some types
> may not be amenable to ordering (types that generate other types, say
> ?)

I don't think there's any reason to consider any order relation on a type to be part of the type. It's a different relation. Also, every type that can carry information has multiple possible orders.

Some orders may come defined by the system, or part of some library, but that doesn't make them fundamental. The RM doesn't have anything about order as part of its definition; one defines order on top of it.

> Also, types that you may want to use in non-equi joins.

Note that one can consider a non-equijoin as an equijoin on 0 attributes with a further join on the non-equality relation. Equijoin is fundamental; non-equijoin is not.

Note that since equijoin is fundamental, equality must be supported for every type. The mechanism for this may be system-defined or type-author-defined, but the system must have some way to tell whether two values are the same.

> At the end
> of the day, the restrict and join operators really don't care; they can
> hand off evaluation of the comparisons to operators you've defined, and
> as long as they return a boolean result that's fine. (Which might lead
> to the "!!!" up ahead ...)

Agreed.

> > > However, there's a great big "!!!" sign on the road ahead; can you
> > > guess what it is yet ?
> >
> > I am looking for them. Please share the one you see.
>
> In my last paragraph, I used this phrase :
>
> "they can hand off evaluation of the comparisons to operators you've
> defined, and as long as they return a boolean result that's fine."
>
> Think about this a little further, with specific reference to complex,
> structure types (and RVAs especially). The relational model may offer a
> get-out clause, though.

I'm not sure what you're referring to. Maybe it's that the equality function might be expensive? If so, that offers no theoretical impediment. Join is guaranteed to complete and return a value (assuming it is well-typed;) it is *not* guaranteed to be fast.

Marshall Received on Mon Jun 05 2006 - 01:33:27 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US