Re: The State of Native XML databases

[Jeff Dexter]

Parsing a date string, no, parsing 10,000 date strings, quite possibly. I
would strongly suggest to query authors out there that if strong typing is
available in the product they use that, for the sake of performance and to
avoid runtime casting errors, they use it.

That's not to say they have to, and in fact many use cases, such as querying
streaming sources, are often forced to use weak typing, and it works quite
well for those cases. Nonetheless the more up-front knowledge an engine has
in regard to what it's querying and the types of the nodes involved the
better it should perform, especially when using types like date, double,
etc.

Jeff. 

-----Original Message-----
From: http://x-query.com/mailman/listinfo/talk [mailto:http://x-query.com/mailman/listinfo/talk] On Behalf
Of John Snelson
Sent: Tuesday, August 21, 2007 5:32 AM
To: Andrew Welch
Cc: http://x-query.com/mailman/listinfo/talk
Subject: Re:  Re: The State of Native XML databases

Andrew Welch wrote:
> But it can only do any of those things if you tell it that the String 
> '2007-08-21' is a date, and not just a String?
> 
> Giving <date>2007-08-21</date> to the database can't be enough...

Sure, that's why XSLT and XQuery allow you to cast values - there are even
special rules that automatically cast values from an untyped XML document
which make life easier in that case.

> The way I was reading this thread was that if the type information was 
> stored in the database, the cost of creating the xs:date would be 
> incurred once and not once per query that uses the value?

That's possible, but not mandatory. Besides, parsing a date string is
probably not going to be the bottleneck in a well designed XML database.

John
_______________________________________________
http://x-query.com/mailman/listinfo/talk
http://x-query.com/mailman/listinfo/talk