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.
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.
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.
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.
<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.)
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
