Modèle de base de données et solde calculé, mysql

Question

Une autre question d'un programmeur d'application qui essaye la première fois de rassembler un modèle de DB lui-même.

Dans mon application, il y a des utilisateurs, des comptes et des transactions. J'ai d'abord eu toutes les tables en 3NF (ou du moins je crois). Ensuite, j'ai décidé d'ajouter un champ d'équilibrage aux utilisateurs, principalement parce que mon code ira en open source et je ne veux pas que les gens gâchent la logique métier du système en changeant le code PHP. Ainsi, les déclencheurs et les procédures stockées mettent à jour la balance. Maintenant, il y a la nouvelle exigence que les utilisateurs auront sur leur page de compte une liste de toutes les transactions qu'ils ont faites avec une colonne de solde, afin qu'ils puissent regarder comment leur solde change à chaque transaction. Bien sûr, les transactions et les utilisateurs sont dans des tables différentes.

Comment s'y prendre? L'esquisse de ma solution actuelle affiche une table balance_history avec des clés étrangères pour transaction_id et user_id. Toute autre suggestion? Merci.

Answer 1

Si votre table de transaction n'est pas très grande, je vous recommande de supprimer la colonne solde de la table des utilisateurs. Pour pourquoi balance_history si vous avez déjà une table de transaction? Et je vous recommande fortement de supprimer toute logique bussines des déclencheurs! Seulement les procédures stockées. Je recommande d'utiliser des déclencheurs uniquement pour les opérations réellement transparentes (audit, validations complexes, etc.). En résumé, je pense que vous devriez supprimer la colonne d'équilibre de la table des utilisateurs et écrire à la place view ('UserBalance' par exemple) rejoindre les utilisateurs et la table des transactions. Supprimez toute logique bussines des déclencheurs, appelez plutôt les procédures stockées aproriate. Utilisez uniquement la table des transactions pour afficher l'historique des soldes. Cela est vrai pour les tables pas très grandes (3-4 millions d'enregistrements est ok). Pour les très grandes bases de données, vous devez utiliser des caches distribués, des bases de données verticales, etc.

Answer 2

Le stockage de valeurs calculées dans une base de données est toujours lourd d'erreurs potentielles. Cela étant dit, c'est juste une technique de mise en cache, et les caches sont assez bien compris maintenant.

Cependant, est-il si coûteux de calculer simplement les soldes en cours sur la page du compte chaque fois qu'il est visité? Nous parlons simplement d'addition et de soustraction ici. Peut-être juste en prenant le solde final, qui est mis en cache, et en calculant le solde courant de chaque transaction à partir de ce peut être possible, et économiser beaucoup de travail dans le maintien de votre tableau balance_history proposé.

J'ajouterais aussi que la table balance_history sera difficile à mettre à jour si des transactions plus anciennes peuvent être insérées ou mises à jour. Vous devez ensuite mettre à jour chaque transaction successive pour que cet utilisateur corrige le solde en cours.

La suggestion d'Alexey Sviridov d'utiliser des vues pour les balances en cours est une bonne chose, bien qu'elles puissent être difficiles à écrire (en particulier pour fonctionner efficacement). Les fonctions analytiques d'Oracle sont vraiment bien pour ce genre de choses, mais je ne suis pas sûr que MySQL ait un équivalent.