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

> When I wrote "untyped", I meant that XDb1 performs no type checking.

You are correct. Currently this burden falls upon the XDb1 user (possibly later basic classes and associated operations will be built-in).

> The fact that you can classify 35 as an integer doesn't solve anything.

It can. For example, if john's age 35 is classified as an integer and mary's age 30 is classified as an integer, then user can choose to verify they are compatible and subtract them. If mary's age thirty is classified as a word, then user is burdened to converted it to an integer, if possible. This is approximately what humans do when asked what is "35 - thirty".

> 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.

There is a general philosophical difference between RM and XDb1. RM expect things to be of pre-defined classes(ie age+integer). On the other hand, XDb1 accommodates things of different classes and even new classes (ie age+integer, age+word, age+expression, etc). RM is strict and consequently very reliable. XDb1 isn't strict and consequently less reliable (somewhat like human computers).

> 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.

It is true that most PC programmers expect to know the data type in advance (unless they're working on AI-type projects). There is a computer that initially doesn't know classes such as integers, decimals, fractions and related operations. However its OS allows it to learn them. That computer is between our ears. Did god (assuming he was the programmer) know what classes humans would contrive in advance before he could program the DNA?

> 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.

In the provided solution, there is a separate table for attribute values of each data type: ie T_Attrib_int, T_Attrib_char, etc. It might be possible to replace those with a single table named T_Attrib_variant. Received on Wed May 26 2004 - 02:04:06 CEST