Im building a new fairly complex project and I want to ensure the infrastructure I'm putting together follows the "best practice" for the type of solution Im designing.
My quandary revolves around the design of a system that utilizes time stamp / event / source of data entries.
For example (keeping things simple), I have Table A, which is designed to keep track of "Comments". Traditionally, I would store the AccountID, DateTime, and other common columns within this table; however, my project is log-intensive. All key events (of taking an action) are properly logged, and those events have the AccountID, DateTime, etc. embedded in them; so if I have a log system that stores that information (e.g. AccountID, DateTime, EventType, etc.). As such, the same details in Table A (AccountID, etc) become redundant/duplicate.
I figured omitting the AccountID and DateTime, etc. from the Comments table was the way to go as I could JOIN any queries of the comments to the logs that match to obtain the AccountID.
But am I overanalyzing this? Should I store AccountID, DataTime, etc. in the comment table itself in the event theres data degradation and treat the event table as a separate thing? Or is the act of needing to JOIN an event table (which will be very large) in order to obtain standard query information too burdensome?
Keeping in mind adjustments and history changes are a part of this as well. What if the person updates the comment 3 times? The event system tracks that.
What are the best practice techniques for something like this? Granted I can make it work either way; the question is once a system like this is being hit by thousands of users at a time (if not more), what system is the best route to go considering the duplicate/time issues?
Thanks!
My quandary revolves around the design of a system that utilizes time stamp / event / source of data entries.
For example (keeping things simple), I have Table A, which is designed to keep track of "Comments". Traditionally, I would store the AccountID, DateTime, and other common columns within this table; however, my project is log-intensive. All key events (of taking an action) are properly logged, and those events have the AccountID, DateTime, etc. embedded in them; so if I have a log system that stores that information (e.g. AccountID, DateTime, EventType, etc.). As such, the same details in Table A (AccountID, etc) become redundant/duplicate.
I figured omitting the AccountID and DateTime, etc. from the Comments table was the way to go as I could JOIN any queries of the comments to the logs that match to obtain the AccountID.
But am I overanalyzing this? Should I store AccountID, DataTime, etc. in the comment table itself in the event theres data degradation and treat the event table as a separate thing? Or is the act of needing to JOIN an event table (which will be very large) in order to obtain standard query information too burdensome?
Keeping in mind adjustments and history changes are a part of this as well. What if the person updates the comment 3 times? The event system tracks that.
What are the best practice techniques for something like this? Granted I can make it work either way; the question is once a system like this is being hit by thousands of users at a time (if not more), what system is the best route to go considering the duplicate/time issues?
Thanks!