[ZODB-Dev] Indexing and dates/times

[Pedro Ferreira]

> So, the issue is that you have multiple items with the same
> key. This is simply handled by using sets as values ion a BTree.
> There are existing index implementations that do this.
>
>    
Hmm... no, in fact the problem is that most of the time I will have only 
one value per index entry.So, in a relational DB i would do something like:
>> SELECT * FROM table WHERE timestamp>= X AND timestamp<= Y
>>
>> Since I cannot do this with ZODB,
>>      
> I don't know what "this" is. Range seaches? SQL? BTrees and various
> index implementations based on the,m support range searches.  of
> course, ZODB doesn't support SQL.
>    

Yes, I know ZODB doesn't support SQL, I was just trying to demonstrate 
my use case.
What I meant was that in relational DBs a query like the one above can 
be performed over an arbitrary table, without the need for having an 
extra data structure for indexing.

>> I'd have to have a BTree, indexed by
>> timestamp... however, as you said, if I want "to the second" granularity, I
>> will rarely have two items with the same key (which makes it pretty
>> useless).
>>      
> I don't know why it is useless, but it is easily handled.
>
>    

It's not useless. I'm sorry, I have used the wrong word. I meant that a 
range query will normally involve the union of a higher number of sets 
as the granularity gets smaller and smaller. If there is only one item 
per index entry, the union operation will take longer... I assumed that 
the more BTree entries we have, the more buckets we will have to fetch 
from the DB, for a given range query. But I am probably wrong...

>> So, I was wondering if there is some data structure I can use for this, as
>> this seems to be a pretty common use case.
>>      
> That's why the various indexing(/catalog) schemes already support it.
>    

So, if I need an index where items can be queried by date, and range 
queries can be performed efficiently, an IOBTree will do the job? As I 
mention above, my only concern is the number of sets that will have to 
be joined.

Thanks, once again,

Pedro

-- 
José Pedro Ferreira

Indico Team

IT-UDS-AVC

513-R-0042
CERN, Geneva, Switzerland