If I have a col within a table "plan" -- which gives subscriber plan types, for listings on a site (alongside "nonplan" - where we contact them directly, no listing on the site. Subscribers can belong to both or either of these. And switch at any time. )
a) I'm debating on whether to move "plan" on to its own table, since its values are upgradeable - upgrade from "standard" to premium" plan. To decide this my question is: since these are paid for plans would a transaction table in itself be enough for a history of the upgrades? (credit card purchases) (not paid for yet but will soon be, and design needs to account for this - so there is no tansaction table yet. "plans" values are "3",4","5" where 3 is free and 4,5, paid for. ) I'd much rather keep "plan" in its existing table. Makes things much simpler when users switch from "plan" to "nonplan".
I have script that would update "plan"in its existing table while sending a copy off to another table if need be (would mean two of the same values in seperate tables however, but the history value would typically never be searched on.)
Suggestions? What is the best way to do this to track the history of upgrades? Is sending duplicate values off into a table okay?
