I looked through the project some more and threw away some parts and tried to make sense of the rest.
Here’s a list of all tables and fields:
department field was related to role based access control stuff which I might throw away because they never have more than 1 web administrator.
If I did merge everything into a single table I’d made another table just for storing the id’s of articles to include in the next auto-generated newsletter, so I could drop the
newsletter field. I’d do the same for articles featured on the home page so can drop the
The tables that contain content that resembles a real magazine article are
communitycorner, corporatebriefs, news, news_members, and reports. Sometimes an outside person or company will submit their own articles for publication which is why there is both
author_firm fields on the
corporatebriefs table but might be useful to have them on all tables listed above. Sometimes an outsider or government agency will also send over a PDF file or video that needs to be published, so the
author_firm field could also apply to
So that leaves me with the 5 custom fields on
associations table and 5 on
events table (I’m dropping
annual field). I’m wondering if there’s an elegant way of keeping just those 10 fields in 1 or 2 separate tables and combining them with the main table as needed.
I’m considering making one big table named
posts that contains all the articles similar fields and then making mysql “views” named
associations that join the 10 custom fields to their corresponding records in
posts table. Good idea? No?
If I merge them all into 1
posts table I’ll also drop the disgusting category field and use a cross reference table so any post can be in as many categories as necessary.
I’m also wondering if I should move
addedwhen, addedby, last_edited, and editedby to a separate table.