I have a pattern that's something like this:Create a database model UsagePlan which stores how many usage tokens a paid customer receives in exchange for its respective monthly fee. Through my ORM (Django), I override the save method to not allow any writes to this table from my code.I create a fixture that specifies the usage plans as my client specified them. Every time I deploy, this fixture gets loaded into the database (idempotently).I create another model LiveUsagePlan. When a user turns into a paid customer, an instance of this model is related to the user and stores a copy of the UsagePlanthat they picked.My client updates their usage plans, so I update the fixture and deploy. Current customers aren't affected since their LiveUsagePlans don't change (grandfathered), however all new customers' LiveUsagePlans will copy the new UsagePlansI am skeptical of this pattern, as I made it up and have never seen it anywhere else. I've also never seen fixtures used outside of the context of tests. Are there any glaring problems that I'm not seeing? What's the best way to handle this kind of mostly-static state?
Using fixtures to maintain static database assets
database;web development;web applications;database design