Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)

On 18 May 2004 13:01:31 -0700, Neo wrote:

>> the schema should be strictly seperate from the data
>
>In XDb1's data model there is no separation between data and schema at
>the db level, however the app logic can choose to make those
>distinctions if needed.
>
>> and the datatype of the data should be known.
>
>In XDb1's data model, "data type" is simply an additional
>classification of a thing. If it needs to be known, it should be
>classified as such (ie. 35 isa integer).
>
>> And this is exactly the reason why I'd never use XDb1 for serious work,
>> unless I encounter a problem area where the advantages of allowing untyped
>> data outweigh the disadvantages.
>
>I think, I finally understand what you are saying. In the example,
>since 35 was only classified as an age, it appears to be "untyped".
>The example was simple. 35 can also be classified as an integer. Each
>thing in XDb1 can have multiple classes, one of which can function
>similar to its "data type".

Hi Neo,

Rereading what I wrote and what you replied, I may have chosen the wrong word. (I'm Dutch - English is not my native language).

When I wrote "untyped", I meant that XDb1 performs no type checking. The fact that you can classify 35 as an integer doesn't solve anything. I want to be able to subtract John's age from Mary's age and be sure that the result is their age difference, in years. That can only be achieved if the database can be told that EACH age should be a whole number. That can be done very easily in every RDBMS that I know. I have not yet seen how that constraint can be built into XDb1.

Of course, you can allways do it in the application. But for something I need very common, I prefer to have support built-in into my tools.

Note that I expect that at least 99.9% of my future work will require the datatype of a value to be known to the programmer. This is based on 20 years of experience (where the percentage has always been 100%); the 0.1% insecurity margin is included because I know that the unimaginable is usually just about to happen.

Note also that MS SQL Server, the RDBMS I do most work on at the moment, supports a datatype "sql_variant", that will store basically everything. I have never used this datatype, not have I ever seen a question in any SQL Server related newsgroup (and I participate in quite a few of them) where this datatype would be the answer. And I expect I never will.

Best, Hugo

-- 

(Remove _NO_ and _SPAM_ to get my e-mail address)