Hi Erick, don't really understand your question and what exactly the point is, but anyway. yes - there is a DB where data are stored, however the scheduling is just a part of the whole picture. I thought to use Solr for search / filtering results - the schedule (availability) is just one filter from the whole search process. Does it make sense for you? May I ask if you are a Solr specialist? I don't know how serious I have to take in account your answers.
thank you, Rich -----Original Message----- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Tuesday, September 21, 2010 20:36 To: solr-user@lucene.apache.org Subject: Re: tricky range query? So it sounds like you're working on some kind of scheduling app? Which makes me wonder why you're using SOLR. Much as I like it, this sounds more like a database application than a search application. What am I missing? Best Erick On Tue, Sep 21, 2010 at 1:05 PM, Papp Richard <ccode...@gmail.com> wrote: > Hi Erik, > > first of all, thank you for your answer. Let me detail a bit the amount of > data: > > - actually services going to persons, and the time table is per person (a > person can have multiple services). > - there will be around 10.000 person (or maybe 100.000 - I would like to > say > rather 100.000 than have problems later) > - but time table can differ from week to week, so each person has many time > table (one for each week) => so this means that if they have the timetables > for ~3 months (12 weeks)... 100.000 x 12 ~ 1.000.000 timetabels... and each > time table has 7 days... and on each day we have many periods (as someone > books a service, the timetbale will be modified, and possible will result > in > time gaps, like I show in the example)... so all in all there are too many > data, is it? > - I've checkte the "trie", but couldn't find too much info. I don't know if > it could be a solution to us e it or not - I'm not a solr expert. > > regards, > Rich > > > -----Original Message----- > From: Erick Erickson [mailto:erickerick...@gmail.com] > Sent: Tuesday, September 21, 2010 14:40 > To: solr-user@lucene.apache.org > Subject: Re: tricky range query? > > How efficient it would be I don't know, but depending on how > many services you're talking here, efficiency may not be > that big of a deal... > > But storing each interval as its own record along > with a duration should work. You could then form a query > like duration:[90 to *] AND start_time:[* to 1500] AND > end_time:[1500 TO *]. I'm not sure I'd want that kind of > query on a gigabyte of records... > > But without knowing some more details, it's impossible to > say whether this would be at all suitable... > > Best > Erick > > On Tue, Sep 21, 2010 at 4:41 AM, Papp Richard <ccode...@gmail.com> wrote: > > > Hi all, > > > > > > > > shortly my problem: I want to filter services based on timetables, let's > > consider the next timetable for a day: > > > > > > > > on the date of 15.10.2010: > > > > 10:00 - 11:00 > > > > 12:00 - 12:30 > > > > 14:30 - 16:00 > > > > 17:00 - 20:00 > > > > > > > > how could i store the timetable in Solr and efficiently search in it > > (let's say filter those timetables which has an availability at 15:00) ? > > > > not to mention, that each service has a duration (so, if the service > takes > > 90 mins, filtering by 15:00 shouldn't return the previous timetable, > > because > > there is not enough free time (just 60 mins in the above example)) > > > > > > > > how to solve this? any hints? > > > > > > > > regards, > > > > Rich > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature > database 5419 (20100902) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature > database 5419 (20100902) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5419 (20100902) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 5419 (20100902) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
