Home/ Questions/Q 3432028
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T07:23:55+00:00

I’m using Firebird 2.1 and I’m looking for the best way to solve this

  • 0

I’m using Firebird 2.1 and I’m looking for the best way 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!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There are advantages and drawbacks to all three choices. Whis one is best depends on details you have not provided. In general, don’t worry too much about selecting three or four entries out of a hundred thousand, provided the indexes you have set up allow the right retrieval strategy. If don’t understand indexing, you’re likely to be in trouble no matter which of the three choices you make.

    If it were me, I would go with choice B. I’d also store any attributes of a reminder in the table for reminders.

    Be very careful about whether you identify an event by EventId alone or by (UserId, EventId). If you choose the latter, it behooves you to use a compound primary key for the Event table. Don’t worry too much about compound primary keys, especially with Firebird.
    If you declare a compound primary key, be aware that declaring (UserId, EventId) will not have the same consequences as declaring (EventId, UserId). They are logically equivalent, but the structure of the automatically generated index will be different in the two cases.

    This in turn will affect the speed of queries like “find all the reminders for a given user”.

    Again, if it were me, I’d avoid choice C. the introduction of harmful redundancy into a schema carries with it the responsibility for some very careful programming when you go to update the data. Otherwise, you can end up with a database that stores contradictory versions of the same fact in different places of the database.

    And, if you really want to know the effect on perfromance, try all three ways, load with test data, and do your own benchmarks.

    • 0