Wols Lists wrote:
> On 15/12/10 00:18, Darren Duncan wrote:
> The point I'm making is that a list doesn't contain any ordering *data*
> - it's inherent in the fact of a list. A list is an abstract concept. In
> Pick, I can store a data structure that IS an abstract list. In an rdbms
> I can't.
>
> Put another way, in Pick the function "storelistindatabase()" and
> "getlistfromdatabase()" are, at a fundamental level, direct inverses -
> there's a one-to-one mapping.
>
> In an rdbms, the function "storelistindatabase()" has an inverse
> "getdatafromdatabase()" which returns something completely different
> from what went in.
I would expect that any RDBMS which has a "storelistindatabase()" would also
have a "getlistfromdatabase()". Sure, it may fail if you call the latter for
something which isn't a list, but then I would expect the same in Pick, unless
everything in Pick is a list.
>> If Pick has any understanding of the data itself which is higher
>> level, other than external metadata which is also bit strings, then it
>> would be doing modeling in order to do this, such as to treat text in
>> text-specific ways.
>
> Here again, we come to a fundamental mis-match between the relational
> view of things, and the Pick view. In the relational view, if the table
> does not have a column definition, there is no column. The definition,
> by definition, defines the column :-)
>
> In Pick, the DICTionary de*scribes* the column. If there's no
> definition, the column can still exist. You just don't know what's in it
> :-) Pick uses the description to understand the data, relational uses
> the definition to define the data.
>
> Without a definition, you can't model. So Pick doesn't. It understands,
> instead.
From my perspective at least, a relational database works more like a Pick
database than you think; and this is reflected in Muldis D. I recognize that
some other people see things in a way that are more different, and SQL reflects
this.
A primary difference as I see it is that tuple + relation + scalar values are
conceptually the basic building blocks of a relational database while Pick uses
other things. Obviously, if what you want to store is exactly like a basic
building block, then doing so will be simpler.
In Muldis D, you can work with any arbitrarily complex value, a relation or
otherwise, without first declaring a type for it. The *only* purpose of
declaring a type in Muldis D is for defining a constraint on a variable or a
parameter; it also helps with optimization since the DBMS can then better
predict what is going to be used where.
For example, you can simply say:
@:{ { pizza_name => 'Hawaiian', toppings => { 'ham', 'pineapple' } } }
... without declaring anything first, and what you have there is a binary
relation value literal consisting of a single tuple of 2 attributes, and one of
those attributes' values is a set of 2 elements.
You could also take any value and introspect it, whereby you can be given back
a
type definition that *describes* the value.
"the database" in Muldis D is in the general case simply a non-lexical variable
whose type is, loosely, "any tuple whose attribute values are relations". You
can declare that the type of "the database" is more specific, such as with
specific columns and such, but that is optional (though commonly done).
So in Muldis D, you can simply say "store this X" and it will, without you
having to define columns or whatever first. And I consider this to be
completely valid for a relational database.
This sounds like how you describe Pick.
Now SQL can't do this on the other hand, but that's a limitation of SQL.
(As a tangent that is more on-topic, the Muldis D approach is more in common
with SQLite than by many other SQL DBMSs in that a SQLite row column value can
be of any (scalar) type, and you don't have to declare a column to be of a
particular type in order to store a value there; if you do then that is just a
local constraint rather than a fundamental limitation.)
>> Atomicity is just an abstraction for certain kinds of error detection
>> and correction. Pick can't be truly atomic, but only provide an
>> illusion of such, and so can other DBMSs, including relational ones,
>> as the implementations provide. (And even then, operating systems are
>> known to lie about whether data has been physically written to disk
>> when you fsync.)
>>
> You're wrong there. Pick IS truly atomic. Yep, OSes can lie, and if Pick
> accepts that lie then carnage will occur, but the word "atom" is greek
> for "indivisible". Let's take my pizza for example. "Hawaiian = ham,
> pineapple". That is an atom. Take away any part of it, and it's no
> longer a hawaiian pizza. And as far as Pick is concerned (if properly
> programmed :-) that will remain, for ever and always, an atom. It comes
> in as an atom. It passes through as an atom. And it's fed out to the OS
> to put on disk as an atom. Pick is truly atomic
Is this meant to say that Pick is not designed to look at parts of things it is
fed, but rather just takes what it is input as indivisible and can only
store/fetch it as a whole?
> (even if the combo "Pick
> on a computer" isn't).
Are you trying to say that Pick can exist in some form other than "Pick on a
computer"? Is Pick a specification or a DBMS implementation?
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
