Subject | Re: [firebird-support] DB design best practices - which solution is faster? |
---|---|
Author | Peter Faulks |
Post date | 2010-11-19T12:12:53Z |
What are you going to store in the calendar table?
Surely you would be querying based on a certain date range?
Index on a date column
SELECT userid, cal_date, whatever, whatever_else FROM calendar WHERE
cal_date BETWEEN <begin_date> AND <end_date> AND reminder = 1
Surely you would be querying based on a certain date range?
Index on a date column
SELECT userid, cal_date, whatever, whatever_else FROM calendar WHERE
cal_date BETWEEN <begin_date> AND <end_date> AND reminder = 1
On Fri, 2010-11-19 at 09:22 +0100, Zd wrote:
> Hello All!
>
> I'm looking for the fastest method to solve this issue.
>
> I'm writing a calendaring application. Different users' calendar entries are stored in a big Calendar table.
> Each calendar entry can have a reminder set - only one reminder/entry.
>
> Statistically, the Calendar table could grow to hundreds of thousands of records over time, while there are going to be much less reminders.
>
> I need to query the reminders on a constant basis.
>
> Which is the best option?
>
> A) Store the reminders' info in the Calendar table (in which case I'm going to query hundreds of thousands of records for IsReminder = 1)
> B) Create a separate Reminders table which contains only the ID of calendar entries which have reminders set, then query the two tables with a JOIN operation (or maybe create a view on them)
> C) I can store all information about reminders in the Reminders table, then query only this table. The downside is that some information needs to be duplicated in both tables, like in order to show the reminder, I'll need to know and store the event's starttime in the Reminders table - thus I'm maintaining two tables with the same values.
>
> What do you think?
>
> And one more question: The Calendar table will contain the calender of multiple users, separated only by a UserID field. Since there can be only 4-5 users, even if I put an index on this field, its selectivity is going to be very bad - which is not good for a table with hundreds of thousands of records. Is there a workaround here?
>
> Thanks!
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Yahoo! Groups Links
>
>
>