Looking for opinions on process...

[RIRedinPA]

I am building a production work flow chart for magazines. There are 28 magazines in total. The chart will show the production process for each item in one issue of a magazine. I have a CSS table kind of like an excel spreadsheet and use AJAX to do live updating - i.e. Editor writes a comment in a text area I use an onchange event to update the db.

 

They also want to see the history for each field of each record. For example, one field is copy drop, they want to see the timestamp for when the editor says they actually did the copydrop (editors are sneaky bastards and will drop the copy at 6P on a Friday and then complain on Monday that they got the copy to the artist on Friday why isn't the layout done at 7A. So something like copydrop could have a history of:

 

Timestamp: 01/29/2009 2:13PM

Comment: I dropped the friggin' copy now get off my back.

Editor: Joe Editor

 

What will initially be displayed to the user is just the timestamp in the field copydrop. Below the initial data row of the table I hide the full history row, click a button and it slides open to show all the history of every field. (Hope all this is clear).

 

OK, so now onto my question. Right now I have one table for all the content and one for all the history. I started thinking this morning though that 28 magazines, all together there's probably 400 issues for the year, 30-40 content items per issue, probably at least 3-4 comments per item,  in a short time there will be a lot of items in these two tables (especially the history one) and I don't think it'll be so much a performance issue as a maintenance one. Would breaking this into multiple tables - one per issue of each magazine and one for the history of each magazine make more sense from a performance/maintenance issue?

[JonnoTheDev]

Read up on normalisation before creating/modifying you tables if you are unsure.