Re: Operationalize orthogonality

Pickie wrote:
> When I read "...arithmetic a bit differently than they way you were
> probably taught in school", my hackles raised. I may have had a
> university education!

You may have. Nonetheless, there are good reasons for providing different systems for, among other things, arithmetic.

> I don't think you follow the discussion. It's not about the relational
> model, it's about implementing types in DBMS's. Tony was specifically
> separating types from the relational model.

So, too, was I. Your question, "[h]ow to represent a count ...using only booleans and relations," established the context for my answer - which slightly expanded on what the explicit requirements for boolean types are before, clearly, moving the discussion to types.

   I think that his comment
> about the "obvious requirement for a boolean type" says as much as if I
> said "We use digital computers so of course we use binary codes".

Actually, no. I didn't want to press the point, but the notion that "zero and empty string" are false and "all else [are] true," while convenient in some languages, does not necessarily hold for userdefined  numbers and strings in the relational model. If you want those values in those types to be interpolated that way: fine, define the needed operators which give results of boolean type.

> My problem is in seeing how to get from a super-simple DBMS which only
> has boolean types to one which has more complex types. Specifically, I
> can't see how this can be done _without_ introducing any new concept,
> idea, element, whatever.

And that's exactly why a systematic mechanism for type definition is required.

   Moreover, I don't think a comparison operator
> is enough.

Well, for the relational model, it is.

   It might seem obvious that the binary string "11" is
> greater than "10", but it's not true if I use Grey code rather than
> BCD.
Very true. But that's a "type" issue, not a relational model issue.

   And in both cases, we rely on the order of the bits - and how
> does that concept get represented in booleans only?

Again: it shouldn't. Both Tony D and I have been trying to make this point. And, as far as the relational model is concerned, we have set forth all the concepts, ideas, elements and whatevers needed to store data in an RDBMS. (By the way, all that's explicitly needed is an equality comparison operator that yields a boolean -- not the "less than, equals, greater than" operators that are generally known as comparison operators. Does it make sense to compare two MP3 values and determine whether one is greater than the other?)

  It's a circular
> arguement to re-state how BCD and ASCII codes work - I get that
> already!

This remark confuses me; I don't understand the reference. Received on Thu Jun 01 2006 - 03:37:19 CEST