How to design database table to store process status? I have an application (ProcessMonitor) that monitor some constantly running process at fixed interval (like 30 seconds, but can be changed by user) and store the process status to a database table, the table looks like this:

| id         | int             | NO   | PRI | NULL    | auto_increment |
| pid        | int             | YES  |     | NULL    |                |
| pstatus    | int             | YES  |     | NULL    |                |
| timestamp  | datetime        | YES  |     | NULL    |                |

Obviously, this table grows very fast because for every single process, there will be 2880 new records inserted into table per day if the interval is 30 seconds. Given the fact that the process's status is not changed very often  may keep one state for several hours), I decide change the logic of ProcessMonitor to write to database only when the status of process changes using the same table design. There are two problems for the new approach:


There is no way to track when and how long ProcessMonitor is stopped.
Unable to keep track of the change of monitoring interval.


I am feeling that I may need to change the design of the table, but I've not found a good solution, could anyone suggest me a better way to store the process status?
You'll be averaging about a million records a year, which shouldn't be a problem given the table is fairly narrow. I don't see anything wrong with your design (other than a NULLable primary key?). You should be able to easily track when and how long each process takes by comparing timestamps. This is accomplished using a self join.