On 14/12/10 19:49, Darren Duncan wrote:
> Wols,
>
> I'm just going to say a few things right now for brevity rather than
> individually responding to all your points.
>
> I think the point of a relational database is to provide an effective
> and flexible tool for users to describe any reality, and it is the job
> of the database to enforce any logically-defined business rules the
> user gives them.
Mmmmm ... delete the word "relational" from that sentence and then
you're a lot closer to the truth. At which point I'd turn round and say
that a RDBMS does not fit that description :-)
>
> Perhaps in my explanation I may have been mixing up capabilities of
> the relational model itself with capabilities of programming languages
> that natively support the relational model and also do things that
> aren't part of that model itself but are complementary. But said
> programming languages in this case, such as SQL or Muldis D, *are*
> what the DBMS does.
At which point we diverge from the Pick model. SQL and Muldis-D have no
equivalent in the Pick world. (Or they *can* do. Like so much in Pick,
using the database query language is *optional*.)
>
> Wols Lists wrote:
>>>>> 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 !!! :-)
>
> 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.
> For that matter, you didn't define what "list" means. I took it to
> mean "ordered array" given the context since you didn't specify.
>
And you would be correct.
>> "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.
>
> There is more than one way to represent particular information, and
> meaning relates to context. A computer or model only says what users
> tell it to. If I made some assumptions I shouldn't have, maybe I was
> working from incomplete information and was just providing an example.
Isn't that what typically happens in a relational database :-) I'm being
sarky, but I think there's rather more than a grain of truth there.
But this is the perfect example of the difference between "model" and
"store". I'll use my list of names, but it applies equally to your list
of fruits. You *correctly* assumed that a list and and an ordered array
are equivalent. But in an ordered array, the index is metadata and the
value is data. So why did you store the index along with the value? I
did say "don't mix data and metadata", didn't I :-)
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.
(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?)
>
>>>> 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 ...
>
> Maybe you should qualify what you mean by "the DBMS" and "the app" then.
>
> I define "the DBMS" as being the virtual machine in which the
> programming language runs which manages the storage of user data and
> the enforcement of user-defined business rules/constraints for that
> data. Typically the programming language is SQL but it could be
> Muldis D or something else instead.
Except that in the Pick model the DBMS is the (virtual?) machine which
manages the storage of user data.
>
> I define "the app" in this case as being user code that uses the DBMS
> and typically lives external to it.
I'd agree with you here.
>
> Both of these go along with conventional usage I think.
Because most database guys are relational guys, therefore relational
usage IS conventional usage. And because relational theory has such a
massive mind-grip, most relational guys can't conceive of anything any
different ...
>
> How much the DBMS can do and what interface it provides to the app
> depends largely on what programming language it runs inside.
>
> As I understand it, Pick is a DBMS by this definition whose language
> isn't SQL.
Except that Pick is a DBMS that DOESN'T HAVE a language (although, as
I've said before, this isn't a hard and fast rule :-)
Oh and yes, when it does have a language that language can be (and often
is) SQL.
>
>> 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 :-)
>
> Once again, define what STORE means with examples.
>
> I had interpreted STORE conventionally as being how a programming
> language or DBMS or computer represents a list or persists it.
As above, to me STORE means "take what you're given and persist it
UNCHANGED". Which, if the app passes an ordered array, is exactly what I
can't see an RDBMS doing. As opposed to "model", which means "hit it
with a sledgehammer until it's in a form I can cope with" :-)
A programming language such as Fortran or C might store a list as an
array - where is the index *in* the array? It doesn't exist. Emacs will
actually store it as a list (after all, emacs is written in LISt
Processor :-). Pick stores it as a list. It's only an RDBMS that
converts metadata (the index) to data, reorganises it into a set of
tuples, and then splats it randomly over the disk :-)
>
>> 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" :-)
>
> What is considered distinct layers is all about abstraction or
> representation or implementation. I see what the DBMS does as one
> layer and what app code outside the DBMS as the other layer.
>
> Why don't you define the layers you expect to have with examples which
> aren't unnecessarily complex?
Done, above. (I accept that a lot of your difficulties arise from not
realising this layer just doesn't exist in a Pick system :-)
>
>> 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 :-)
>
> That was just the simplified example. You will note that I defined
> the array-of-foo type separately from the variable in the Muldis D
> example, and explicitly stated that it could be the type of an
> attribute or you could nest. But even if you couldn't nest, nesting is
> logically equivalent to having say 2 tables in a one-to-many
> relationship, so you could represent it flat if you want and they are
> interchangeable in what they can do.
>
>> In my original challenge, I said "store a bunch of pizzas and their
>> toppings lists".
>
> Okay, a more realistic example, that I can work with:
>
> material Pizzas ::= relation-type {
> over Pizza ::= tuple-type {
> attr pizza_name : Text
> attr toppings : Toppings
> ::= relation-type { attr topping_name : Text }
> }
> primary-key { pizza_name }
> key { toppings }
> }
>
> ... and then you can define variables of that type and so on.
>
>> Oh - and as an aside, Pick wouldn't need a transaction. The entire
>> operation is atomic :-)
>
> That's just a SQL-specific limitation. Other DBMS languages can or do
> make that atomic, and Muldis D does.
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 :-)
Cheers,
Wol
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
