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

From: thirdrock (iktaccounts)
Date: 05/21/04 

Date: Fri, 21 May 2004 18:05:20 +1000

On Tue, 18 May 2004 11:27:12 +0200, Hugo Kornelis
<hugo@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

Relevant Pages

  • Re: Three Kinds of Logical Trees
    ... that includes all code that uses the dbms api would have all such units ... a variable of type int, with an int value and invoke a method ... ... >> database would have all the data and functions it needs to address ... I have no plans to design a language, but I'm happy to learn anyway ...
    (comp.databases.theory)
  • Re: Another idea from pick goes mainstream...
    ... A relational database has nothing to do ... SQL is one of the ... is now considered THE language for any dbms implementing the relational ... Then, XML came out. ...
    (comp.databases.pick)
  • Re: If you were developing a database in Forth...
    ... database that worked well, and then Dennis Ruffer provided source code ... to do the same thing in some other language and it failed it was ... It doesn't matter if the project was a stunning success or a ... that failure was the language we invented. ...
    (comp.lang.forth)
  • Re: selecting a language
    ... > languages to write our application in, as Progress is becoming ... Progress is a 4GL language so it is very rapid development. ... database access from GUI code. ... Java has a lot of built in support for it. ...
    (comp.lang.java.programmer)
  • Re: OO vs. RDB challenge
    ... >> loans have greater risk so not all users that can approve a loan ... >> database engine for that matter)? ... >> language for somethings, ah well. ... string group) ...
    (comp.object)