Re: [bdbxml] Indexing suggestion

Hi Steve,

Steve Howe wrote:
> Monday, April 10, 2006, 11:36:05 AM, you wrote:
> 
>>Thanks for your suggestion, Steve. We have considered using paths to 
>>specify indexes, and have rejected the idea before now.
>>The trouble comes when you try to match available indexes against a
>>given query to see which ones you can use - the more specific an index 
>>the less queries you can use it in, and the harder it is to tell if you 
>>can use it in a particular query.
> 
> Thanks for your response, and I'm sorry for writing back only now.
> 
> As I see, to write an appropriate index expression is is responsibility
> of the programmer and not BDBXML's, right ? There are XPath expressions
> that cane be very generic, such as "//*". To *allow* such indexes to be
> written created is BDBXML's responsibility. Limiting what BDBXML can do
> because the user could be not clever is weird and just too sad. The
> documentation could just instruct those users to add "//*" and such
> generic expressions. Let's not strip the power because users are dumb...
> and if someone is dumb, the last thing he'll want to do is playing with
> BDBXML.

DB XML, more than any other XML database I know of, assumes it's users 
are smart. Other XML databases I have seen only allow their users to 
turn on value indexes, or turn them off. DB XML has chosen a more 
flexible approach, which is to specify the name of the element or 
attribute to index and to choose from a large number of potential 
indexes for it.

This flexibility does not come without penalty. Choosing the wrong 
indexes will mean that your query will not benefit from them (or worse, 
could be slower). Also the query optimiser in DB XML must be very smart 
to identify which indexes it can use at a specific place in the query, 
and then to choose the best index from amongst the available ones.

The more specific the definition of an index, the smarter the query 
optimiser will have to get in order to apply the index to a query. 
Similarly, the more complex and flexible the definition of the index, 
the harder it is to be clever about performing updates efficiently.

> The problem with the current scheme is that it is too inflexible. For
> instance, if I have a container with two kinds of documents:
> 
> <user>
>   ...
> </user>
> 
> <group>
>   ...
> </group>
> 
> ... and I want to index all nodes under "user" but not those under
> group, I can't do it, because default indexes will act on the whole
> document. I could do it, however, using two XPath indexes:
> 
> /user/*
> 
> /group

A container is the unit of granularity for an index specification. If 
you have two type of documents with such different indexing needs, I 
would suggest that you should put them in two different containers.

> I hate to be annoying, but I would like to ask you to reconsider
> implementing it unless there is some reason it could not be done. The
> current indexing API would not need to be changed; it would even be just
> converted to generic XPath expressions meaning the same thing.
> Everything would be just compatible.

We always consider our user's suggestions seriously. I don't think this 
indexing scheme is appropriate for DB XML right now, however the ideas 
behind it certainly contain some challenges and food for thought in the 
future.

John

-- 
John Snelson, Berkeley DB XML Engineer
Sleepycat Software, Inc
http://www.sleepycat.com

Contracted to Sleepycat through Parthenon Computing Ltd
http://blog.parthcomp.com/dbxml


------------------------------------------
To remove yourself from this list, send an
email to [email protected]