Q: Optimizing notification check I am making a site with a notification system, on every page load AJAX is run to query a table in a database called notifications. I do not want to show the # of notifications one has, but only the type. There are 4 types. I currently have JSON just get UNIQUE of the type column and then do a check for each type.
Because this will be run many many times, I want to be sure it is well optimized. I am guessing one way would be to not run this check for new notifications someone has all 3 until they click on the notification bar (i.e. until they have a chance to clear one of them).
I was also wondering though if you think it would make a difference (positive or negative) for me to make the types each a prime#, and then multiply them together server-side, this way instead of sending 3 different ints I'm sending the product of 3 primes, then to check for each type I just mod(%) each type. I also want to know if you think  it may make a difference but such a tiny one that I shouldn't worry about it. I only worry because it will be run on every page load and don't want users to feel the site is slow.
schema:
`notifications` 
(`id`,`from`,`to`,`type`,`optional_message`)


A: 
I was also wondering though if you think it would make a difference (positive or negative) for me to make the types each a prime#, and then multiply them together serverside, this way instead of sending 3 different ints I'm sending the product of 3 primes, then to check for each type I just mod(%) each type. I also want to know if you think it may make a difference but such a tiny one that I shouldn't worry about it.

FFS! For some systems this kind of multiplexing is important - but it is usually implemented by ORing bit fields. But for HTTP, the amount of bandwidth this would save is ridiculously small. Don't bother.
If you really need to optimize this, the way to do it would be to cache the data serverside (MySQL will do this for you with a semi-intelligent algorithm).
With four entities per key, denormalizing the data using a materialized view will not yield performance benefits unless te data is very skewed.

A: Minimizing the amount of data sent might seem very little in this case, but consider adding more notifications in the future. If you use a bitmask you can have tons of different notifications and still send tiny data. Compare development cost vs benefits, since you're very concerned about this optimization, I'd go with the bitmask.
About how often the check for new notifications should be performed - if the user has all notifications, clearly you don't need to check anymore. Another optimization that I'd consider is changing the interval of updates. Meaning that if a user has 0 notifications, I'd check i.e. every 5 seconds or so, when he has 1 notification, I'd check every 10 seconds, etc. I don't know what this notifications represent, but generally having received a lot of notifications already means the chance to get another, different type of notification, is lower. Can you give some more details, I'm not sure if this is the case?
