Location Structures Approaches, Pros & Cons

#11

"Daniel Dittmar" <daniel.dittmar (AT) sap (DOT) corp> wrote

Quote:

Mark Johnson wrote:
No that's a relation. In describing a race, the attributes might
include, gate. The gates are ordered.

But as I understand it, relations are not supposed to be sorted. So I
wondered that if a relation includes a horse's ranking, as a 'thing'
intrinsic, that one is trying to say that relations can be sorted?

In a database that is not set oriented, you could simply add horses to a
race, the gate number would be implicit through the insertion order.

It's this implicit data that contributed to the confused state of affairs
before databases became widely used. If you assign a sequence number to the
record or tuple at the moment of insertion, and carry that around as data
all well and good. But if you use the list itself as implicitly carrying
that information payload here's what can happen:

Someone who is unaware of the information payload in the given order
discovers that sorting the list in some other order will yield superior
performance, so that person reorders the list. No harm done, right? Then
someone else comes along who is aware of the list ordering principle, but
not of the recent reordering, uses the data to determine the original entry
order.

Wrong data, wrong answers.

If anything can go wrong, it will. The above is not a hypothetical
scenario. It's happened thousands of times.

#12

David Cressey schrieb:

Quote:

"Mark Johnson" <102334.12 (AT) compuserve (DOT) com> wrote in message
What do you mean by "how far does one carry that"? All your examples
are typical of cursors, not relations. Every time you say "list",
think "cursor". Cursors are always sorted, but relations are not.
No that's a relation. In describing a race, the attributes might
include, gate. The gates are ordered.

The gates aren't really ordered. The locations of the gates are ordered,
and the numbers painted on the gates are ordered, but the gates themselves
are not ordered.
Or, to be more precise, one could define a variety of orders over the gates,

like latitude, longitude, date/time of building, numbering, distance from left/right,
even alphabetically according the the name of the horse or jockey in them for
a particular race.
Given the right attributes you can sort according to all those orders in your
database.

Whether a few grams of paint (the number on the gate) is "related" to a
particular gate is an entirely different matter and has nothing to do with any
ordering.

There's no "intrinsic" order for anything. Just the way you choose to order.

Lots of Greetings!
Volker

#13

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

Quote:

No that's a relation. In describing a race, the attributes might
include, gate. The gates are ordered.

The gates aren't really ordered. The locations of the gates are ordered,
and the numbers painted on the gates are ordered, but the gates themselves
are not ordered.

How would you model the beads and rods from
http://mathworld.wolfram.com/Bead-Sort.html with RM instead ? :-)

#14

x schrieb:

Quote:

"David Cressey" <dcressey (AT) verizon (DOT) net> wrote in message
news:ifFKf.9191$qa2.4665 (AT) trndny07 (DOT) ..

No that's a relation. In describing a race, the attributes might
include, gate. The gates are ordered.

The gates aren't really ordered. The locations of the gates are ordered,
and the numbers painted on the gates are ordered, but the gates themselves
are not ordered.

How would you model the beads and rods from
http://mathworld.wolfram.com/Bead-Sort.html with RM instead ? :-)
A model is something static.

So, without fully understanding the sorting algorithm I'd probably
have rows with a row number and beads with a column number belonging to
a row.
Then I'd update the row number of the beads while sorting.

Lots of Greetings!
Volker

#15

Mark Johnson wrote:

Quote:

But as I understand it, relations are not supposed to be sorted.

Relations have no implicit order. This is part of the definition.

Quote:

So I
wondered that if a relation includes a horse's ranking, as a 'thing'
intrinsic, that one is trying to say that relations can be sorted?

It depends on what you mean by "sorted." If you mean, can
we change the definition of relation to include the idea that
it has implicit order, then the answer is "no." If you mean,
can we pass the relation to a sort function that will examine
the attributes of the relation and return an ***ordered set***
that has the same elements as the original set, then the
answer is "yes."

Reviewing the fundamentals of set theory might be in order;
this is a very basic question.

Marshall

#16

On Tue, 21 Feb 2006 10:56:13 +0100, Bob Hairgrove
<invalid (AT) bigfoot (DOT) com> wrote:

Quote:

Cursors are always sorted, but relations are not.

Clarification:
Cursors always have an ordering of some kind, even if not explicitly
specified by an "ORDER BY" clause -- in which case it will probably,
but not necessarily, reflect the physical storage order of the data.

Relations are not sorted at all.

--
Bob Hairgrove
NoSpamPlease (AT) Home (DOT) com

#17

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

Quote:

Mark Johnson wrote:

But as I understand it, relations are not supposed to be sorted.

Relations have no implicit order. This is part of the definition.

That's how I understood it. It was considered an advantage not to
allow sorting.

Quote:

So I
wondered that if a relation includes a horse's ranking, as a 'thing'
intrinsic, that one is trying to say that relations can be sorted?

It depends on what you mean by "sorted." If you mean, can
we change the definition of relation to include the idea that
it has implicit order, then the answer is "no." If you mean,
can we pass the relation to a sort function that will examine
the attributes of the relation and return an ***ordered set***
that has the same elements as the original set, then the
answer is "yes."

Reviewing the fundamentals of set theory might be in order;
this is a very basic question.

It really is. It suggests almost mere semantics. In other words, if a
relation is sorted, one simply claims that it is something - else -
rather than use the word, sorted. Therefore, it is neither sorted, nor
unsorted, neither ordered nor unordered.

#18

Daniel Dittmar <daniel.dittmar (AT) sap (DOT) corp> wrote:

Quote:

Mark Johnson wrote:
No that's a relation. In describing a race, the attributes might
include, gate. The gates are ordered.

But as I understand it, relations are not supposed to be sorted. So I
wondered that if a relation includes a horse's ranking, as a 'thing'
intrinsic, that one is trying to say that relations can be sorted?

In a database that is not set oriented, you could simply add horses to a
race, the gate number would be implicit through the insertion order.

SQL is inherently 'set based'. The database by its use of tables is
'set based'. These were based on the proposals of Codd, years ago.
Simply inserting another record, another entity (some here prefer to
call the entire row, a tuple), says nothing about the sort. But to add
a sort is to create a sorted relation.

By the way, the order in which the horses break is important to
gamblers. It conceivably would be weighted by other factors.

Quote:

In a set oriented model, any sort order must be explicitly defined
through additional attributes, in this case the gate number. The
database itself does not know that this attribute has to do anything
with ordering (1). To get the values in the order defined through that
attribute, you have to add an ORDER BY clause, which is a feature of the
cursor, not of an relation.

So while the gate is a fundamental attribute of the entity, its
presence does not contribute to any sort because it is defined away
into a domain of cursors, and not relations?

#19

Bob Hairgrove <invalid (AT) bigfoot (DOT) com> wrote:

Quote:

On Tue, 21 Feb 2006 10:56:13 +0100, Bob Hairgrove
invalid (AT) bigfoot (DOT) com> wrote:

Relations are not sorted at all.

But when they are, the sort or result of the sort is by definition no
longer the - relation?

Doesn't that just strike you as mere semantics? A relation is unsorted
because by definition any sort attribute - isn't?

#20

Volker Hetzer <volker.hetzer (AT) ieee (DOT) org> wrote:

Quote:

Given the right attributes you can sort according to all those orders in your
database.

But the issue is whether even theoretically, can a relation be termed
an ordered relation when it supposedly is defined as being unordered,
by definition?

At what point does any type of sort create an ordered relation? Or is
the very possibility simply defined away? which makes it look more
like a wordplay or semantics, by the common sense of the term.

I wonder if the confusion isn't over this idea of transcendence or
immanence and internal machine representation. In such confusion it
might lead some to insist that there is no such thing as intrinsic
order, when in fact what is being manipulated by a database, which is
really what this is all about, might become useless chaos if its
intrinsic order remains unaccounted.