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

On Fri, 21 May 2004 23:27:31 +0200, Hugo Kornelis <hugo_at_pe_NO_rFact.in_SPAM_fo> wrote:

> On Fri, 21 May 2004 18:05:20 +1000, thirdrock <iktaccounts at optusnet
> dot
> com dot au> wrote:
>
> (snip stuff I agree with)
>
>>> 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?
>
> I'm afraid I don't see what point you're trying to make.

That there are a range of problems where allowing untyped data outweigh the disadvantages.

>
>
>>> 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.
>
> In a relational database, I can define Colour with a datatype that
> accepts
> RGB values instead of english names.

Yes, but CURRENTLY you cannot accept BOTH. The same is true of all strongly typed languages, not just relational databases.

>
> But I (the developer) have to do this. I'll have to write the code for
> the
> overloaded = and + operators.
Someone always has to write the code to do this, be it the end developer or the vendor of the database. Just because RDBMS exist where the code to enforce the data type exist doesn't mean that some developer didn't write the code to do that.

> Overloading gives the designer the possibility to create lots of extra
> possibilities for the user. But the user still can't use things that are
> not pre-defined by the designer. That's the point I was trying to make:
> XDb1's parser will gladly accept ages of 7, "over the top", "slightly
> older than I am" or even "I think therefore I am" without bothering to
> check if it has any overloaded operators that are able to do anything
> useful with that data.
>
Well, is that correct? If I can subclass or extend the functionality of the XDb1 functions (which by the way I don't know whether or not it is possible), then I can add that type checking myself. There are C++ bindings to the XDb1 API ...

Or can I ?

Have fun,

Ian

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/