I am currently building a rails application based around insurance. There is an admin section where the staff can control the system tables, mostly what appears in drop down lists, although some are more complex with their own associations. The main model in this application is the policy, this needs to hold/link to information in many other tables, e.g. claimants, defendants, the level of cover, the users etc. Each of those may have their own associations such as linking to a person which in turn links to addresses etc.
One of the more complicated tables that the policy links to is the overall level of cover which holds the financial information to determine the premium, payments etc.
When a policy is created I need to take a snapshot of all that data. If the policy is amended by an admin user later there needs to be version control, even on the associated data.
I'm wondering if anyone has any general solutions to this problem. Currently I'm pondering over orphan records, single table inheritance, leaving the system table links in place but making that data non-editable, coping the data into a fields in the 开发者_如何学Pythonpolicy table (making it a text box on edit, select box on create) or creating two tables, one for live, one for the templates.
So far the best I can think of is a collection of the different methods above based on the applications needs. This must be a general problem in applications!? Do you have any better ideas/advice on how to tackle this type of problem?
For versioning of models, vestal_versions (github.com/laserlemon/vestal_versions) plugin might be helpful.
Without knowing exactly the needs of the application it is difficult to determine what the best solution is.
However the solution that immediately comes to mind for me based upon what I have read would be the "orphaned records" that you describe, but I do not see why they need to be orphaned.
You could create a model like this:
class PolicyHistory< ActiveRecord::Base
belongs_to :policy
end
class Policy < ActiveRecord::Base
has_many :policy_histories
end
The policy History could contain your snapshot of all the policy details and associated data at a particular moment and even who made the changes.
You could flatten the associations and store that data in a bunch of columns. However this may cause issues when altering any of the involved table since you will have to update the history table as well.
A solution to this might be serializing the complete snapshot as a hash. The policy history table would then be able handle any changes to the involved tables.
I hope this is of some help to you!
精彩评论