Re: separation of church and state?

David Portas wrote:
> "David Cressey" <cressey73_at_verizon.net> wrote in message
> news:X4PNi.3890$9r2.3214_at_trndny04...
...
> I disagree. Even in SQL, allowing ORDER BY in a view creates some tough
> problems.
>
> What would it actually mean for a view to be ordered? Presumably it would
> mean that at least some queries against that view should exhibit some
> pre-determined ordering. Now please define exactly which such queries
> against a view may and may not be ordered in that way (queries with joins,
> projections, aggregations, etc), including those with joins to other views
> which also have orderings of their own.
>
> Assuming you can define such a set of rules, ...
>

My cut is that only the attributes that the view presents can be ordered, however I may be misunderstanding the question. Not to change it, let me ask a different question.

If I make a union view of two base tables (or for that matter of two relations) that have a column/attribute A of type T, I presume the union view can't possibly have that same attribute A with a type T2 that is not equal to type T (I'm assuming here that the system doesn't support some kind of type inheritance). But say both of the "bases" have a key constraint such that two tuples t1 and t2 couldn't both be present in either "base". If I define no key constraint for the view, I would think it would be okay for both the t1 and t2 tuples to appear in the view. So the type is propagated, but the key constraint isn't. That seems a kind of unavoidable "rule" to me. I would think an ordering on a base table/relation is kind of similar to the key constraint and maybe there is an even stronger reason for it not to propagate, ie., if ordering is not part of the algebra, how could it? Received on Sat Oct 06 2007 - 22:21:02 CEST