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.
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.
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.
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.
> "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.
>>> 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.
I define "the app" in this case as being user code that uses the DBMS and
typically lives external to it.
Both of these go along with conventional usage I think.
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.
> 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.
> 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?
> 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.
> To follow up on my basic mathematics comment - in a list of rational
> numbers, what is the ordinal position of the number "1"?
Normally there isn't an answer to this.
> The basic proofs of "what is infinity" rely on the fact that this
> question has no answer ...
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
