Re: Activity DB Design Discussion
Not sure if you took my post on the other thread the wrong way, but it was meant to bring attention to the real problem, not to flame. Hopefully, I am not being labeled a troll here.
I am happy that you recognize the real problem, though still disagree with you on the data normalization issue. I think you were headed in the right direction with the format_activity() way of doing things. It would be prudent to take another look at this and see if we can put our heads together to solve any of the problems you were having that led you to think about abandoning this.
I think it is a mistake to defend WP way of handling things because its the way it has always been, or because its popular. BP may be a WP plugin, but it has its own set of complex problems that need to be solved, and more advanced solutions need to be designed. There are many ways to refactor code using wrapper classes, etc, and maintain backwards compatibility.
My two cents on the activity stream is that it should be designed as a registry of component activities. It must have a clearly defined class interface that must be adhered to. Any time the activity stream is called/viewed, the registry calls template methods (which are defined by the class interface) for each record found. This is very similar to how the format_activity() idea works, except all of the components are currently hard coded into the activity component, which is not very extensible.
I don’t think there is a way around caching/denormalizing to solve the performance issue. The options are to keep the data normalized, and call it on demand, with the option to cache, OR to pre-format it the way you like, which is really just denormalized data but not in the traditional sense. In any case, the original data needs to be normalized, and any cached or denormalized data can’t be treated as a stand alone “object.” Its only there to speed up performance.
