Best practice for several eventlog tables and on-site-notifications?

Question

Having a setup now, where multiple q2a installations (let's call it "network") run on the same database, with different prefixes (but shared user database), I want to achieve a "network" wide notification for events.

The events are stored per site (according to the prefix), for instance:
qa1_eventlog
qa2_eventlog
qa3_eventlog

Having the on-site-notifications plugin installed, it only checks for the events on the according site, but not network wide.

My question: Should I simply modify the on-site-notifications plugin to read all eventlog tables?

Or should I create another way of handling those events, e.g. storing all new events in a unified qa_notify_eventlog table?

What would be best practice, especially with eyes on speed.

Comments

Nice idea, I hope Scott will take of this while implementing notifications feature in Q2A.

btw, Do you use single db for multi-site or separate db for each network site?

If you are using single db and if there are more than 10 sites then there will be too many tables in one db. I'm not sure if it create issue for db maintenance . please share your thoughts. thanks

---

I ended up modifying the on-site-notifications plugin to read all eventlog notifications. Note: I created a notification count in the database (separate table), so it can check if there is a notify count of greater than 0 for each (performance reasons).

The question about best practice is still open.