W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Points of order on this WG

From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
Date: Fri, 26 Jun 2009 15:33:35 -0700
Cc: public-webapps WG <public-webapps@w3.org>
Message-Id: <F9EB4A7C-36E4-43F2-B032-8261BFBF6449@oracle.com>
To: Maciej Stachowiak <mjs@apple.com>
I have a tutorial available to understand how one can use Berkeley DB  
to store data with multiple fields [1]. If you are only interested in  
understanding how to do look up by one or more of them, please skip to  
slide 51.

If this doesn't help, I can write up another explanation for the  
issues that are outstanding.

Hope this helps.


[1] http://www.oracle.com/technology/products/berkeley-db/tutorial-berkeleydb-ds.html

On Jun 26, 2009, at 1:13 PM, Maciej Stachowiak wrote:

>>> It's also not clear to me if a BDB-level API is sufficient for  
>>> developer needs. As I understand it, it's basically a giant  
>>> dictionary with unstructured keys and values. So it's not  
>>> providing much over LocalStorage, except for prefix matching and  
>>> the ability to hold large amounts of records or records that are  
>>> individually large. There's no way to efficiently query by one of  
>>> several fields, as I understand it.
>> I trust that you are relatively new to storing data with B-trees.  
>> They are at the heart of Oracle's indices so efficiency is out of  
>> question. If you are wondering how can people store complex data  
>> items with multiple fields and repeating values, look at Berkeley  
>> DB Java Edition, which supports the EJB 3 persistence model [5].  
>> FYI, there is no significant difference between the APIs of BDB  
>> Java Edition and the original BDB. They also have identical  
>> licensing requirements.
> Your references do not appear to explain on a technical level how  
> one stores data with multiple fields in a way that you can query  
> efficiently by more than one of them. I would appreciate a brief  
> explanation.
Received on Friday, 26 June 2009 22:35:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC