We're building a simple web based system whereby somebody adds a record, a CMS page for example, that gets approved by someone in charge before being shown on website.
If the author decides to edit that page later, we create a draft based on the live page; on approval it will replace the old live page.
Rather than doing complete version control we simply record whether there are live and/or draft pages.
This functionality is required across multiple 'things', not just pages.
Is it better to store these two records in the same table or use a mirror table?
I don't like having two tables with the same structure. We'll have to query out the drafts all the time when displaying the data.
No. One entity type, one table.
Reasons to reconsider:
Draft records outnumber live records by a factor of thousands to one.
Security conditions require that some users who access the database directly have certain rights over draft or live records at the GRANT/REVOKE level but not over the other type of record.
A second design to consider would be one table for the Items and a second table for LiveItems. The second table contains only the IDs for the Items that are live. That way you're maintaining your single table design, but you can find the LiveItems by joining your one-column table back to the main table.