Question

I want to improve the speed of a notification board. It retrieves data from the event table. At this moment the events MySQL table looks like this

id | event_type | who_added_id | date

In the event table I store one row with information regarding a particular event. Each time a users A asks for new notifications, the query runs through the table and looks if the notifications added by the user B suit him (they have to be friends, members of the same groups, have previously chatted). Table events became big, because of the bulky query the page loads slow. I'm thinking of changing entirely this design and, instead of adding one event row and then compare if the user's event suits or not, to add as many rows as interested users. I would change the table events structure as follows:

id | event_type | who_added_id | forwho_id | date

Now, if user B creates an event which interests other 50 members, I create 50 rows with the same information and in the 'forwho_id' field I mention those 50 members which must get this notification. I think the query will become much more simple and it will take less time to search through it. How do you think: 1. Is this a good approach in storing such kind of data or we should avoid duplicate data at any cost? 2. How do you think the events table will behave if the number of interested users will be not 50 but hundreds?

Thank you for reading this and I hope I made myself understandable.

Was it helpful?

Solution

Duplicated data is not "bad", and it's not to be "avoided at all cost".

What is "bad" is uncontrolled redundancy, and the kind of problems that come up when the logical data model isn't third normal form. It is acceptable and expected that an implementation will deviate from a logical data model, and introduce redundancy for performance.

Your revised design looks appropriate for your needs.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top