Hi Duncan,
Exactly the sort of answer I was afraid of ... but I think my answer is
going to horrify you as much as yours horrified me.
Let's explain. In antiquity, Euclid said "parallel lines never meet". He
used that and logic to build a model of geometry (which other people
then built on further to create things like Classical Physics). The
point is, it's all a self-consistent *Mathematical* *Model*.
Then Einstein went to the south seas, observed the 1917 eclipse and said
"Hey, we have two straight lines here, that have crossed in two distinct
places. Sorry Euclid, your maths does not describe my reality".
You're talking maths, I'm talking science, we have the potential of a
major conflagration here ...
On 14/12/10 01:29, Darren Duncan wrote:
> Wols Lists wrote:
>> On 13/12/10 22:44, Darren Duncan wrote:
>>> I am also very interested in these subjects.
>>>
>>> I believe that the relational model can accurately model anything in
>>> the real world, and that this can be implemented in efficient ways,
>>> with physical structure taking hints from logical structure.
>>
>> But can you STORE it?
>
> Yes. Anything that a computer can represent, a computer can store.
>
And? Did you really mean to say that? We were talking about relational
databases, not computers. Of course a computer can store a list - it can
run Pick which stores lists ... (or it can run emacs !!! :-)
>> A challenge I throw out - please STORE a list in the relational
>> model. Oh - I'll just add a couple of sensible constraints. (1) as
>> seen by the application, there mustn't be any duplicate data (I
>> believe the relational model says you mustn't duplicate data, yes?).
>> And (2) - again as seen by the application - you mustn't mix data and
>> metadata in the same table. Worded a bit differently, don't get your
>> cardinal and ordinal numbers mixed up :-)
>
> Okay, I'll take this up. I will model an array of elements, where
> each element has arbitrary/possibly-user-defined type Foo, in terms of
> a relation.
>
> I also argue that the array index is necessary in any model or
> implementation, relational or not; the user explicitly cares about
> this because they want an order associated with a list of Foo that
> isn't intrinsic to the Foo values themselves.
"proof by arrogance" :-) "because I need it, so do you". Let me give you
a list. "Walter, Walter, John, Anthony". True, there's no inherent order
in the values themselves, but there IS an inherent order in the MEANING
of those values. It's a paternal lineage. But the ONLY valid
ordinal/cardinal conclusion you can come to is that Anthony is last,
because I have no sons. You can't assign an ordinal of four to me
because Walter Sr had a father (I happen to know his name was Walter,
too). In fact, with no more effort than checking another list on my
computer, I could change my *apparent* ordinality from 4 to about 10.
I'm quite happy with your argument "ordinals have meaning in relational
theory, because relational theory assigns them a meaning", but it's a
circular argument. As indeed, at fundamental, are ALL mathematical
arguments.
But to argue that ordinals have meaning as a matter of course is just
bullshit. I've just given you a scientific "the exception proves the
rule" proof, and in maths the basic proofs of number theory rely on the
fact they're meaningless.
>
> Sure, the language can provide syntax for operations such that users
> don't actually have to use the index numbers, but they still have to
> be there, and users have explicitly said they must by declaring their
> list is ordered. And indexes must exist somehow; every implementation
> of an array must have some way of referring to and finding an element
> regardless of language.
>
>>> Also, that you can model any data structure simply over tuples and
>>> relations, including arrays and bags, and likewise implement such
>>> tuples and relations with physical arrays behind the scenes.
>>
>> Again, you use the word *model*. Isn't this pushing all this
>> complexity back out into the app - where it DOESN'T belong?
>
> No. All the complexity is stored and enforced by the database, right
> where it belongs, and not with the app.
I'm beginning to see where the fault lines are developing. You've got a
middle layer I don't have. I'd leave all that complexity to the DBMS,
but you've got a database layer between the DBMS and the app ...
>
> Since the format I describe of using a binary relation to represent an
> array is canonical for Muldis D, it has related shorthands, and by
> using those, users don't see the index numbers which conceptually exist.
>
> Muldis D short-hand for declaring the array type:
>
> material Foo_Array ::= array_of.Foo
>
> Muldis D longer-hand for same:
>
> material Foo_Array ::= relation-type {
> over tuple-type {
> attr index : subset-type of Int where { topic >= 0 }
> attr value : Foo
> }
> primary-key { index }
> where { #topic > max(topic{value}) }
> }
>
> One way to declare a database relvar of that type:
>
> relvar list_of_foo : nlx.lib.Foo_Array
>
> Or Foo_Array can be the declared type of a lexical variable, or a
> function parameter, or another relation attribute, or whatever.
>
> Here is a SQL analogy:
>
> CREATE TABLE "list_of_foo" (
> "index" INTEGER CHECK "index" >= 0,
> "value" FOO,
> PRIMARY KEY ("index")
> );
> CONSTRAINT CHECK (SELECT COUNT(*) FROM "list_of_foo")
> > (SELECT MAX("index") FROM "list_of_foo");
>
> Now a relational DBMS can see the above definition and realize that it
> means a simple ordered array, and so can implement and store it as
> such physically if it chooses to; but the implementation choice is
> left to the DBMS.
Hang on a second - you've just said that "the DBMS can see this" ... in
other words, in MY reality, this is part of the application! And "index"
is visible! Game over, I've won :-)
And hang on a third - you've just MODELLED a list, I challenged you to
STORE it. Game over, I've won :-)
Okay, in your reality I think you'd say it's part of the
application/database api, to which I merely reply "and it's another
layer of complexity asking for trouble" :-)
>
> For an example of assigning to said array variable, lets assume for
> simplicity that Foo is actually just Text (if not, then replace the
> string literal for a Foo value literal) ...
>
> In Muldis D, the short-hand:
>
> list_of_foo := ['cherry', 'apple', 'orange']
>
> Muldis D longer-hand for the same:
>
> list_of_foo := %:[index, value]:{
> [0, 'cherry'],
> [1, 'apple'],
> [2, 'orange'],
> }
>
> And the SQL analogy (assume within a transaction):
>
> SET CONSTRAINTS ALL DEFERRED;
> TRUNCATE "list_of_foo";
> INSERT INTO "list_of_foo" ("index", "value") VALUES
> (0, 'cherry'),
> (1, 'apple'),
> (2, 'orange')
> );
> SET CONSTRAINTS ALL IMMEDIATE;
>
> You will see that in all the short-hands, there is no array index
> metadata to be seen. The DBMS API for the application can map these
> arrays-as-relations to its native arrays fairly simply.
Ouch. My fault for not being clear, I suppose, but you appear to have
one table per list. I was thinking along the lines of eg a recipe book -
a load of recipes with lists of ingredients. At one table per recipe,
that's going to be a right pig to manage in an RDBMS :-)
In my original challenge, I said "store a bunch of pizzas and their
toppings lists".
Oh - and as an aside, Pick wouldn't need a transaction. The entire
operation is atomic :-)
>
>>> Ordered lists and bags can be logically binary relations with
>>> index+value or value+count attributes. (That is also the canonical
>>> way to do it in Muldis D.)
Look at it this way. You can convert a list to a bag by *throwing*
*away* information (the information about order). You can convert a bat
to a set by *throwing* *away* information (the information about
duplicates). But you CAN'T go the other way - from a set to a bag to a
list. In other words, the ONLY way to store a list or bag inside a set
is to convert implicit metadata into explicit data. At which point, the
DBMS has now forced the layer(s) above it to manage a load of
information, that it should be responsible for.
>>
>> I think this is what I said above you mustn't do - mixing up your
>> ordinals and cardinals? (And mixing your data and metadata.)
>
> The index is an ordinal, the count is a cardinal and both are just
> data. Lots of actual user data is the same. If we're storing a count
> of apples, or quantity of grain, in our inventory, that count is a
> cardinal number. If we're listing the starting lineup for ball
> players, their order to go out is an ordinal number.
But my point is that either or both may be just plain meaningless in the
real world. For the database to require that they exist is for it to
confuse data and metadata. Take my lineage above. The ordinal of any
name in the list is MEANINGLESS METADATA. For the database to force it
into a "data" mould is to deny reality. If I really do want to know, in
Pick I can ask the database "what is the current ordinal of Walter", for
example. Or "give me the name currently at position 4". And it will
*calculate* the current value.
>
> If you want the DBMS to enforce that they are not mixed up, as you
> could do with plain integers, you can declare wrapper types to keep
> things separate; for example:
>
> scalar-type OrdinalInt { attr where_on_line : Int }
> scalar-type CardinalInt { attr how_much : Int }
>
> ... and then use those instead of Int; the DBMS will not allow any of
> those 3 to be substituted for the other, being strongly typed.
Actually, I'd rather I didn't even have to worry about them ...
>
>>> It is perfectly valid to nest tuples and relations inside each other
>>> (these *are* valid 1NF), and so likewise you can have record field
>>> values that are sets or arrays or tables or whatever.
>>
>> Which is where Pick scores, this is easy to do and flows naturally
>> from the data model. But it does it the other way round - the logical
>> structure takes hints from the real-world-physical structure (and the
>> database designer makes sure the physical database structure mimics
>> the real-world physical structure).
>>
>> Cheers,
>> Wol
>
> -- Darren Duncan
>
To follow up on my basic mathematics comment - in a list of rational
numbers, what is the ordinal position of the number "1"?
The basic proofs of "what is infinity" rely on the fact that this
question has no answer ...
Cheers,
Wol
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
