Re[2]: Possible new key () function (Was: Re: [xsl] Finding t

[Steven.C.Kienle@xxxxxxxxxx]

  We should remember that early database technologies required keys to 
  be explicitly used during data access.  SQL improved things, but it 
  still requires that someone define what keys are likely to be used 
  (via CREATE INDEX statements/constraints).
  
  Perhaps this can be changed now, but I think a lot more thought would 
  need to be put into it before a workable alternative could be 
  designed.
  
     Steve


______________________________ Reply Separator _________________________________
Subject: RE: Possible new key() function (Was: Re: [xsl] Finding the 
Author:  Kay Michael <Michael.Kay@xxxxxxx> at Internet-America
Date:    09-01-2001 10:14 AM


> > In this case xsl:key will know in advance about all possible
> > operators and could build the indexes in an optimal way in order to 
> > guarantee most efficient key() performance.
  
The more I listen to this discussion, the more convinced I am that SQL got 
it right and XSLT got it wrong: keys should be used implicitly, behind the 
scenes, when the optimizer decides and not when the user decides. Rather 
than having new variants on the key() function, we should do away with the 
function entirely.
  
Mike Kay 
  
 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
  

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list