On 15/12/10 00:18, Darren Duncan wrote:
> Wols Lists wrote:
>>> I think that part of the problem here is that you didn't define what
>>> STORE means. So please clarify with examples as what you see
>>> qualifies as "STORE a list" and what doesn't.
>>
>> As opposed to "model". To store something is to put it into the database
>> unchanged. To model it is to alter it before you store it.
>>
> <snip>
>>
>> My app passes { Walter, Walter, John, Anthony } to Pick. Pick writes {
>> Walter, Walter, John, Anthony } to disk.
>>
>> Your app passes { Walter, Walter, John, Anthony } to the
>> application/database transformation layer. SQL transforms it into { {0,
>> Walter} {1, Walter} {2, John} {3, Anthony} } and passes it to the RDBMS.
>> The RDBMS splits it up into the tuples, and saves them to disk.
>
> From your description here, it sounds like Pick is fairly low level
> and just deals with bit strings; eg, each key and value it deals with
> is just a bit string.
Correct. Except your "value" is actually "bunch of attributes" if I
understand "key" in the typical sense ...
>
> That is the only way I see it would make sense to be able to say that
> to "store" is to put into the database unchanged. Because as bit
> strings is how the computer natively represents things, so the DBMS
> and app would use this in common, and anything else is an abstraction.
ALL is an abstraction :-) At least, once you've moved away from the real
pizza physically on your plate :-)
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.
>
> 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.
>
> When you go above bit strings, different programming languages and
> applications and APIs assume different things about what bit pattern
> particular character strings or numbers or arrays or whatever have.
>
>> (Now when the next programmer comes along, or you come back six months
>> later, how do you know that the 0,1,2,3 are, in fact, totally
>> meaningless and only there to be sorted on to make sure the names are
>> passed back in the correct order?)
>
> Documentation, either in the form of a descriptive schema or otherwise.
And if the programmer didn't bother to document? Or he got it wrong? Or
he misunderstood? Point is, I'm not relying on some guy storing yet more
metadata in some other datastore somewhere else. My data inside my
database is logically identical to my reality outside. There's a
one-to-one bidirectional mapping.
You've basically just admitted that your database is not complete or
accurate - you need more information stored elsewhere.
>
> <snip>
>> You misunderstand me - seriously so! In Pick, that operation is atomic
>> inside the database, right through until the data passes out of the
>> database into the hard disk queue! ANY and ALL RDBMS are unable to
>> provide that guarantee, by simple virtue of being relational databases!
>>
>> That's why Pickies have such a hard time understanding all this fuss
>> over ACIDity :-) If an application write fails sufficiently badly to
>> worry about atomicity, it's not a matter of corrupt data, it's a corrupt
>> hard disk you're worrying about!
>>
>> I don't want to broaden the discussion unnecessarily, but this is where
>> Pick really gets away from the RDBMS model - by nesting tightly related
>> tables you can write (or read) all this stuff in a single atomic hit.
>> Which is how I can prove that Pick will ALWAYS outperform relational for
>> speed - Pick allows me know about the underlying storage, and because I
>> know about it I can reason about it and make predictions about
>> performance. All totally forbidden by relational theory, of course :-)
>
> 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 (even if the combo "Pick
on a computer" isn't).
This, I think, is what gives the relational guys the heeby-jeebies about
reality. In relational, you don't have the problem of "what is an
atom?". Everything is divided down to the ultimate tiny bits. I'm a
chemist by education, a physical chemist by inclination (and a
programmer by trade). Drawing a chemistry metaphor, I'd say relational
theory divides everything down to the quark/gluon level, and deals with
it there. At which point, the question "what is an atom?" just becomes
meaningless. So an rdbms can't be atomic.
But quarks don't exist on their own. They can only exist as part of a
hadron. Bit like attributes, actually. They're fine in an rdbms. But the
real-world-equivalent is an adjective. Which cannot exist on its own -
it NEEDS to belong to a noun - which has no equivalent in an rdbms!
At which point, reality gets really messy. I'd say the computer
equivalent of a noun is an object. But one man's object is another man's
attribute (the obvious example to me is a line-item on an invoice - is
it an attribute of the invoice, or an object in a ledger?). Relational
simply avoids the whole question. Which imho makes it impossible to
"address a problem at the *appropriate* level of detail". The only level
available is the fundamental. It's like trying to do zoology when all
you have available is the laws of physics.
Cheers,
Wol
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
