Je vais écrire un système de crédit simple que l'utilisateur peut " ajouter " "," déduire "Crédits dans le système. Actuellement, je pense à deux approches.
simple: stocker le crédit de l'utilisateur comme Historique basé: Ne stockez pas la balance dans la base de données. La balance est calculée en examinant l'historique des transactions, par ex. ("Ajouter", "déduire")
Les deux cas fonctionneraient, je pense, mais je cherche à voir si une mise en garde lors de la conception d'un tel système, en particulier, je favorise le système basé sur l'historique
ou, existe-t-il une implémentation de référence ou un module open source que j'utilise?
mise à jour: ou existe-t-il un module basé sur rubis / ferroviaire comme
Balance dans la base de données et toutes les actions ("Ajouter", "déduction") sont enregistrées mais non utilisées pour calculer le dernier solde .
authlogic afin que je puisse brancher mon code existant sans réinventer la roue (E.G. transaction, retour, sécurité, etc.)?
3 Réponses :
Utilisez absolument les deux.
La manière basée sur la balance vous donne un accès rapide au montant actuel.
La manière basée sur l'historique vous donne votre audit. La table d'histoire doit stocker la transaction (comme vous le décrivez), un horodatage, la balance avant la transaction s'est produite et idéalement un moyen de suivre la source / la destination des fonds.
Voir le Boîte à outils Ruby pour la comptabilité et Double-entrées PLUTUS GEM .
En outre, si votre système de crédit peut affecter les utilisateurs, je recommande également d'utiliser la journalisation et de lire idéalement à propos de la vérification du journal sécurisé et de la chaîne à horodatage prouvable.
pour les détails de la journalisation Voir: Techniques de garantie Vérifiabilité des fichiers journaux des événements .
pour le code open source qui fait crédit, vous pouvez rechercher: http: // www. gnucash.org/
Absolument. Sans un grand livre que vous avez zéro confiance dans les valeurs du système. Avec un grand livre, vous pouvez valider que les soldes sont exacts.
J'ai travaillé sur un système qui gère les soldes / la comptabilisation d'une petite entreprise de services financiers et peut garantir que cette réponse est correcte de 100%.
L'ajout et la déduction des crédits implique que vous puissiez également être conscient de l'origine de ces crédits et où ils sont allés. Chaque fois que vous entrez dans une situation comme celle-ci, qu'il s'agisse d'une monnaie ou d'une autre quantité numérique à suivre et à prendre en compte, vous devez envisager d'utiliser une comptabilité Ce modèle a fonctionné depuis des siècles et vous donne toutes les fonctionnalités que vous devez pouvoir voir quels sont vos soldes et comment ils doivent être ainsi:
Si vous n'êtes pas familier avec les détails, commencez ici: Double comptage Ou demander à quiconque a pris un cours d'introduction en comptabilité.
Vous avez demandé une solution open source Ruby sur rails que vous pourriez brancher et jouer dans votre application. Vous pouvez utiliser PLUTUS . Voici un extrait de la description de ce projet sur Github:
Le plugin Plutus fournit un système de comptabilité complète de double entrée.
Pour une utilisation dans n'importe quel rubis sur les rails. Le plugin suit le général
Pratiques de comptabilité à double entrée. ... Plutus consiste en des tables qui
Maintenir vos comptes, entrées et débits et crédits. Chaque entrée peut
avoir de nombreux débits et crédits. La table d'entrée, qui enregistre votre
Les transactions commerciales sont essentiellement votre journal de comptabilité.
Plus un pour la comptabilité de double entrée. Un problème résolu.
Oui, utilisez les deux.
Parfois, vous aurez besoin d'unifier plusieurs transactions sous un même toit. Je suggère de créer une troisième table appelée «jetons» qui sera le gestionnaire de paiements et vous unifierez ces transactions regroupées sous ce jeton.
jeton.Transactions = (Sélectionnez * des transactions T Où T.Token = "123") Par exemple
Honnêtement, je voudrais mettre en œuvre les deux et simplement ajouter un crochet à l'historique pour mettre à jour l'équilibre. Cela atténuera la nécessité d'interroger l'histoire pour déterminer l'équilibre à chaque fois. Cela semble particulièrement utile pour les éléments "déduire" où vous voudriez veiller à ce qu'il y ait un crédit ONGUH à déduire.
Si vous utilisez MS SQL Server, vous pouvez utiliser View indexée pour que la SGBD conserve automatiquement le bon équilibre (basé sur l'historique).