Re: separation of church and state?
Date: Fri, 19 Oct 2007 16:27:12 +0200
> On Oct 6, 9:06 am, paul c <toledobythe..._at_ooyah.ac> wrote:
>> I finally sprung for CJ Date's "Writings, 2000-2006" and skimming it,
>> noticed this point in chapter 10. It reminded me of the recent posts
>> about avoiding books that start with silly sentences even though this
>> quote is from page 174:
>> "Ordering, by contrast, is not part of the relational algebra; nor
>> can it be, because its result isn't a relation. This doesn't mean
>> you can't have an ORDER BY operator, of course - it just means that
>> operator isn't part of the algebra as such, and it can't be used in
>> an expression that's nested inside some other (relational)
>> expression, or more generally in any context where the result is
>> indeed required to be a relation. That's why you can't use ORDER BY
>> in a view definition, for example."
>> It seems a little doctrinaire to me. I can agree that the "result
>> isn't a relation" but on the other hand a user could see such a
>> result without knowing that "ORDER BY" was involved and not be
>> faulted for taking it to be a relation. For that matter, in some
>> apps, users take it for granted that all results are arbitrarily
>> ordered and that those results can be used to produce other results.
> I'm not happy with Date's treatment of this issue. It doesn't
> among the different kinds of order for one thing. (Preorder, partial
> order, total order.) For another, it seems to rely on some intuition
> about what ordering is, but he doesn't spell that out and I don't
> think it's even all that good.
> It seems he's assuming that 1) there's only one kind of order, 2) that
> an ordered set is isomorphic to a sequence, and 3) that it doesn't
> what one orders on. In fact, 1) there are at least three different
> of order, 2) is only true for finite totally ordered sets and 3) a
> order applied to a set of attributes that is not a superkey becomes
> a preorder for the relation. I would expect a thorough treatment of
> order within the relational model to address all of these issues.
>> By analogy of separating the logical from physical implementation, if
>> you want to declare a separation of church and state, I'd think you'd
>> need to mention both. Not to tout SQL but I took the above to mean
>> that if a table were declared with an "INDEX", it shouldn't be
>> allowed to participate in expressions of the relational algebra,
>> which seems extreme and somewhat useless to me.
> To me this is a separate issue. On the one hand we really want
> to be able to separate logical results from their performance
> characteristics. On the other hand, it's important that we have some
> mechanism for those writing queries to be able to have some
> model of performance, or anyway some way of considering
> performance when necessary. Virtually all languages don't
> do the first one very well; SQL is an exception here. I can't
> think of an analog in another language to being able to add
> an index and change the performance of a query independently
> from its semantics. That's a pretty cool feature.
It is not a feature, it is the natural result of the abstraction, the separation of what from how that is fundamental to relational model and implementation.
Received on Fri Oct 19 2007 - 16:27:12 CEST