Re: separation of church and state?

#1

"paul c" <toledobythesea (AT) ooyah (DOT) ac> wrote

Quote:

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.

What user ever would? Users never see relations. They see various kinds of
reports (using the word "report" to mean anything users get to see).

Roy

#2

"Roy Hann" <specially (AT) processed (DOT) almost.meat> wrote

Quote:

"paul c" <toledobythesea (AT) ooyah (DOT) ac> wrote in message
news:hoONi.6504$_K.2827 (AT) pd7urf3no (DOT) ..
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.

What user ever would? Users never see relations. They see various kinds
of
reports (using the word "report" to mean anything users get to see).

That depends on what you mean by the word "user". Is the user of a table or
a view a "user"?

#3

"paul c" <toledobythesea (AT) ooyah (DOT) ac> wrote

Quote:

David Cressey wrote:
"paul c" ...

It is a little doctrinaire. Oracle/Rdb (originially DEC Rdb/VMS) has
always allowed ORDER BY in a view definition. No damage was done to the
ability of the user to apply concepts of relational algebra to the task
of
getting useful work done. One could reference such a view inside
another
view, or in any other context where an unordered table would have been
expected, and the results were logically equivalent to the result one
would
have obtained in the absence of the ORDER BY.

Oracle RDBMS, by contrast, has always forbidden ORDER BY in view
definitions. Other than satisfying some people's need for doctrinaire
purity, the RDBMS users gained nothing by this restriction.

...

I think you're extrapolating Date's remarks to a point that he might not
agree with. A table with an index is still a table.

BTW, the doctrinaire folks among us will insist that SQL does not have
INDEX
in the standard. But we all know that SQL databases use indexes to
speed up
queries. And many application programmers appreciate being told what
indexes are present so that they can organize their queries for
performance.

The doctrinaire people will say that the programmers have no need to
know
index information, because it's not part of the logical model. In
theory
they are right. In practice, it helps to provide them with it.

I'm not sure it's a stretch. I feel fairly confident about resorting to
the Information Principle when asking if a result is correct according
to an algebra. Admittedly, I lump aspects such as ordering and indexing
as 'not applicable' when trying to apply the IP. If I may be allowed to
discount those aspects for results, I don't see why I can't discount,
ie., ignore them, for intermediate results.

If I'm reading the above correctly, I think you and I are on the same page.

#4

"paul c" <toledobythesea (AT) ooyah (DOT) ac> wrote

Quote:

David Cressey wrote:
...
I think you're extrapolating Date's remarks to a point that he might not
agree with. A table with an index is still a table.
...

I *suppose* it is but only in the interest of getting along with the
rest of the world, most of whom I think would agree with you. It's just
that I've never seen a formal definition of a table as a mathematical
object, only as a graphical analogy to a relation, without respect to an
algebra.

I wouldn't call a table a "graphical analogy". I'd call it a logical data
structure that serves to implement the storage of a relation.

Quote:

Therefore, I don't understand how dbms's manipulate tables in
a relational way. It seems to me that they must need to manipulate
relations or relation variables instead.

An SQL DBMS manipulates tables, not relations or relational variables.

#5

"David Cressey" <cressey73 (AT) verizon (DOT) net> wrote

Quote:

Oracle RDBMS, by contrast, has always forbidden ORDER BY in view
definitions. Other than satisfying some people's need for doctrinaire
purity, the RDBMS users gained nothing by this restriction.

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, how is the product supposed to
behave when the user breaks the rules by issuing a query that cannot
properly be ordered according to the view definition? Do we disallow such
queries and raise an error or do we silently return a result set that isn't
sorted? In the latter case, the user must be expected to understand when the
rules are being broken and presumably must also know in advance what the
ordering is supposed be. What benefit can the user possibly gain from this
added complexity?

--
David Portas

#6

"David Portas" <REMOVE_BEFORE_REPLYING_dportas (AT) acm (DOT) org> wrote

Quote:

"David Cressey" <cressey73 (AT) verizon (DOT) net> wrote in message
news:X4PNi.3890$9r2.3214 (AT) trndny04 (DOT) ..

Oracle RDBMS, by contrast, has always forbidden ORDER BY in view
definitions. Other than satisfying some people's need for doctrinaire
purity, the RDBMS users gained nothing by this restriction.

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.

Rather than try to answer your question in detail, I'm simply going to
point you to Oracle/Rdb.
It solved all the tough problems you have raised. It worked just fine in
practice. If the user of a view specifies an order, it overrides the order
built in to the view definition. If the view is used in a context that
requires an unordered table, then it uses an unordered table.

I do not know whether or not the Rdb optimizer was smart enough to omit a
superfluous order by step. I don't care, either.

And, if the view was used in the context of a report writer that only
understood sequential data sources, the facility of providing an ORDER BY
clause in the view definition was a godsend.

Quote:

Assuming you can define such a set of rules, how is the product supposed
to
behave when the user breaks the rules by issuing a query that cannot
properly be ordered according to the view definition?

Do we disallow such
queries and raise an error or do we silently return a result set that
isn't
sorted? In the latter case, the user must be expected to understand when
the
rules are being broken and presumably must also know in advance what the
ordering is supposed be. What benefit can the user possibly gain from this
added complexity?

I refer you again to Oracle/Rdb and to its user community. You may think
it's a problem, but it isn't.

Quote:

--
David Portas

#7

On Oct 6, 9:48 am, "Roy Hann" <specia... (AT) processed (DOT) almost.meat> wrote:

Quote:

"paul c" <toledobythe... (AT) ooyah (DOT) ac> wrote in message

news:hoONi.6504$_K.2827 (AT) pd7urf3no (DOT) ..

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.

What user ever would? Users never see relations. They see various kinds of
reports (using the word "report" to mean anything users get to see).

Not really. Users only see a *representation* of a report. The actual
report cannot be seen.

Well, that's not really true, either. Users only see photons reflected
off of the paper the representation is printed on.

Okay, that's a simplification. Since black ink *fails* to reflect,
users
really see the photons reflected off the part of the paper that
doesn't
have ink on it, and their brains reconstruct a mental image of the
glyphs that make up the representation of the report of the relation.

------

All that goofy stuff I wrote above can be argued for, but why?
It's much simpler just to point to a paper with "{1, 2, 3}"
written on it and say "that is the set containing one, two,
and three."

Marshall

#8

On 6 oct, 18:58, paul c <toledobythe... (AT) ooyah (DOT) ac> wrote:

Quote:

Roy Hann wrote:
"paul c" <toledobythe... (AT) ooyah (DOT) ac> wrote in message
news:hoONi.6504$_K.2827 (AT) pd7urf3no (DOT) ..
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.

What user ever would? Users never see relations. They see various kinds of
reports (using the word "report" to mean anything users get to see).

Roy

I can buy that relations aren't visible to the naked eye but I'd say
that users certainly do see representations of relations (even if the
representations are called tables) and the relations are visible in the
mind's eye. Maybe if the word "understand" is substituted for "see" it
makes more sense, after all, predicates aren't physically visible either
but users do need to understand them.
The way I look at it is that Date tries to remind us of the

mathematical nature of relations and that a relation which is a
abstract conceptual is not meant to be seens but to be reprensented.
It is true that it does seem doctrinaire but at the same time it does
make sense. Whether one user does *see* a mathematical function (ex:
f(x)) seems as an unappropriate verb to to use: he just represents it
at some point in time. The user however may *see* the symbological
representation of the function (ex: f(x) = 2x+1) or he sees the
graphical representation of the function (in this case a line).
imho...

#9

"Marshall" <marshall.spight (AT) gmail (DOT) com> wrote

Quote:

On Oct 6, 9:48 am, "Roy Hann" <specia... (AT) processed (DOT) almost.meat> wrote:
"paul c" <toledobythe... (AT) ooyah (DOT) ac> wrote in message

news:hoONi.6504$_K.2827 (AT) pd7urf3no (DOT) ..

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.

What user ever would? Users never see relations. They see various kinds
of
reports (using the word "report" to mean anything users get to see).

[goofy stuff snipped]

Quote:

All that goofy stuff I wrote above can be argued for, but why?

That was pretty much my point: Paul was thinking about possibly true facts
but in an irrelevant framework.

Roy

#10

On Oct 7, 8:40 am, paul c <toledobythe... (AT) ooyah (DOT) ac> wrote:

Quote:

Could be. Maybe one of Date's meanings is that no system that supports
both ordering and some relational algebra is purely relational, even if
the "pure" relational part of it could be isolated in some way from the
rest! If so, calling the paragraph "doctrinaire" might be a bit of a slur.

In order theory, an ordered set is a pair, consisting of a set and an
order relation on that set. It's not a list or anything like that.
The question of data structures only comes up when (in
implementation land) we want to do the computation of putting
the elements in some order. What that looks like is a design
decision, and I don't see any reason why it can't look like a
relation, at some level at least. In other words, it could be a
relation {position, element} in the case of a total order, or
{position, {element}} in a preorder. (It's not obvious what
it should be for a partial order.)

My sense is that Date's ideas about the solution space to
this problem have been somewhat artificially constrained
as a response to what SQL did.

Marshall