W3C home > Mailing lists > Public > xmlschema-dev@w3.org > May 2007

RE: is there any formal commercial identity constraint cases

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 15 May 2007 15:09:44 -0400
To: "Michael Kay" <mike@saxonica.com>
Cc: "'Jones, Kevin'" <kevin.jones@intel.com>, xmlschema-dev@w3.org, "'Le, Yongnian'" <yongnian.le@intel.com>, "'Yu, Zhiqiang'" <zhiqiang.yu@intel.com>
Message-ID: <OF8F7DDCEA.870E439F-ON852572DC.0068AA9B-852572DC.0069203D@lotus.com>

Michael Kay writes:

> As far as I can see you are conjecturing performance 
> difficulties here with no real evidence. I don't think there is
> any reason to believe that the cost of validating identity 
> constraints is likely to be a significant obstacle to real applications.

My intuition matches Michael's, with a couple of minor caveats:

1) Just because one can build efficient id-constraint implementations 
doesn't mean that any particular one you try to benchmark is built to be 
efficient.  Finding a slow implementation doesn't settle the question of 
whether the feature is inherently hard to optimize.  Finding a fast 
implementation at least shows what's possible.

2) I think it's clear that there are pathological uses of identity 
constraints that are likely to be slow.  For example, you could arrange in 
some schema and instance so that the keys would contain a significant 
fraction of the information in a document (a document that has mainly 
attributes, all of which are used in keys);  if the document were 
gigabytes long, then you could get gigabytes of key data.  I expect that 
many implementations will at least sometimes build key tables, and in a 
distorted example like this, those could get large and slow.  My intuition 
matches what I take to be Michael's position:  if you use id constraints 
in the obvious and intended ways, then the implementation overhead should 
be modest or negligible, for some definition of modest and negligible :-)


Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Tuesday, 15 May 2007 19:09:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:12 UTC