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

On Tue, 18 May 2004 11:27:12 +0200, Hugo Kornelis <hugo_at_pe_NO_rFact.in_SPAM_fo> wrote:

>
> Your explanation does raise another question. It looks as if the same
> syntax is used to specify both intension and extension of the model,
> thereby eliminating the distinction between schema and population. My
> guess is that XDb1 would accept the following without complaining:
>
> person isa thing.
> john isa person.
> mary isa person.
> neo isa john.
>
> XDb1 will probably gladly store it - but what does it mean?

Interesting question. It probably means that anything can be anything. Which might have an application in text/html processing. You could easily create XML documents and maybe even schema's by extending XDb1. However, looking at the onerous licensing page on the site, I'm not sure if you would want to do that.

  There might be situations where an untyped database can have
> it's use (I admit that my original choice of words was too harsh), but
> outside of those niches, the schema should be strictly seperate from the
> data and the datatype of the data should be known.

While this is true for structural/relational models, in the OO model you can enforce the datatype or even data behaviour by using member functions. By overloading functions or operators in C++ you can compare 7 to eight, over-the-hill to very-young and anything else you desire. Such functionality may soon make it's way into SQL server as well, so perhaps you don't require the data to be strongly typed as long as the operators on the data members can be overloaded.

Just how this can be done with XDb1, I don't know, as I am concerned about downloading it due to factors mentioned earlier.

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

It is said that if all you have is a hammer, everything looks like a nail. There are a range of applications that require more flexibility than strongly typed languages provide. Often the language of choice used is Perl, and those who use it take the work seriously. But is a language a database, or a database a language? After all, SQL Server stores the data on disk as binary, whether or not it is integer or string, and it is the database engine that reads/writes from/to the disk that enforces the datatype. How is this different from using member functions/overloaded operators in an object database?

>
> In 99.9% of all applications that store a person's age, comparisons have
> to be made: who is younger than 45 years? Who is older, John, Mary or
> Fido? How can XDb1 (or any other type-less database) anser the last
> question is the user has provided the following input:
>
> over-the-hill isa age.
> very-young isa age.
> 7 isa age.
> john is over-the-hill.
> mary is very-young.
> fido is 7.
>
> Most computers I have used will classify very-young as greater than
> over-the-hill and will refuse to compare either of these to 7.

Er, it's the software (or operating system) that does the classification/comparison, not the computer. You did mean software right? And that is not an indication of how computers work, only a limitation of the current software.

>
> Like I said - there may be specific situations where a product such as
> XDb1 has it's use. But it's not (to quote the web site) "the future of
> databases" - not even remotely!

Maybe not XDb1. After all, the customer service skills shown by Neo so far precludes that possibility. But Object databases I would not be so quick to dismiss. XDb1 is the beginnings of an Object database, only it's a technology that I actually saw more than 15 years ago, and which has evolved into a product called Cache (www.intersystems.com)

> is not defined for the character domain and would result in an error. I
> know all this, and I can rely on it - if and only if the database ensures
> that only numeric data will be accepted in the Age column and only
> character data in the Color column.

See my comment above about operator overloading. Also, your Colour could be an RGB value. Where are you then? In weakly typed languages/databases you can accept black and 0 and white and 16777216 as Colours.

Anyway, have fun :)

Ian Received on Fri May 21 2004 - 10:05:20 CEST