2009-11-12 7 views
1

Je suis actuellement en train de construire une application rails autour de l'assurance. Il y a une section administrative où le personnel peut contrôler les tables système, principalement ce qui apparaît dans les listes déroulantes, bien que certaines soient plus complexes avec leurs propres associations. Le modèle principal dans cette application est la politique, ceci doit maintenir/lier à l'information dans beaucoup d'autres tables, par ex. les demandeurs, les défendeurs, le niveau de couverture, les utilisateurs, etc. Chacun de ceux-ci peut avoir ses propres associations telles que des liens vers une personne qui à son tour des liens vers des adresses, etc.Rails: Comment puis-je verrouiller des données dans un enregistrement provenant de nombreuses tables système?

Une des tables les plus compliquées auxquelles la police est liée est le niveau global de couverture qui contient les informations financières pour déterminer la prime, les paiements, etc.

Lorsqu'une politique est créée, j'ai besoin de prendre un instantané de toutes ces données. Si la stratégie est modifiée par un utilisateur administrateur, il doit y avoir un contrôle de version, même sur les données associées.

Je me demande si quelqu'un a des solutions générales à ce problème. Actuellement, je réfléchis sur les enregistrements orphelins, l'héritage de table unique, laissant les liens de la table système en place mais rendant ces données non éditables, copiant les données dans un champs de la table de politique (en faisant une boîte de texte créer) ou créer deux tables, une pour le live, une pour les templates. Jusqu'à présent, le meilleur que je peux penser est une collection des différentes méthodes ci-dessus en fonction des besoins des applications. Cela doit être un problème général dans les applications !? Avez-vous de meilleures idées/conseils sur la façon de résoudre ce type de problème?

+0

Le problème semble être lié à celui des commandes dans les systèmes de commerce. Ils conservent une liste d'éléments de campagne qui sont des clones historiques de produits. Ceux-ci peuvent avoir des clés pour les enregistrements de produits actuels pour la tenue de documents, mais ils clone généralement les données nécessaires en entier dans leurs propres tables. Je ne suis pas sûr si cela aide. –

Répondre

1

Pour le versionnement de modèles, le plugin vestal_versions (github.com/laserlemon/vestal_versions) peut être utile.

+0

le lien était cassé. http://github.com/laserlemon/vestal_versions/ est ce qu'il devrait être. Trouvé un railcast aussi: http://railscasts.com/episodes/177-model-versioning Je ne peux pas +1 cette réponse assez.Je n'ai pas utilisé vestal_versions, mais il prétend faire les bonnes choses, et j'ai vu les dégâts d'essayer de rouler les vôtres. Un système de version DRY est exactement ce que vous voulez. Ce n'est pas une chose insignifiante que vous pouvez simplement vous lancer pour un projet. – cgr

+0

J'aime vraiment le look de vestal_versions, je n'ai pas encore trop regardé mais je ne pense pas qu'il gère les associations? J'aimerais cependant me tromper là-dessus. – tsdbrown

1

Sans connaître exactement les besoins de l'application, il est difficile de déterminer quelle est la meilleure solution. Cependant, la solution qui me vient immédiatement à l'esprit d'après ce que j'ai lu serait les «dossiers orphelins» que vous décrivez, mais je ne vois pas pourquoi ils doivent être orphelins.

Vous pouvez créer un modèle comme celui-ci:

class PolicyHistory< ActiveRecord::Base 
    belongs_to :policy 
end 

class Policy < ActiveRecord::Base 
has_many :policy_histories 
end 

L'histoire de la politique pourrait contenir votre instantané de tous les détails de la politique et des données associées à un moment donné et même qui a fait les changements.

Vous pouvez aplatir les associations et stocker ces données dans un groupe de colonnes. Cependant, cela peut entraîner des problèmes lors de la modification de la table concernée, car vous devrez également mettre à jour la table d'historique. Une solution à cela pourrait consister à sérialiser l'instantané complet comme un hachage. Le tableau d'historique des politiques pourrait alors gérer toutes les modifications apportées aux tables impliquées. J'espère que cela vous aidera un peu!