Base de données de conception de schéma pour la gestion du remboursement du prêt

Question

Nous avons une application web pour le suivi des paiements périodiques pour un prêt, actuellement nous gérons dans une base de données MySQL comme ceci:

Table

loan_payments avec les colonnes suivantes [ id, customerId, installmentNo, installmentAmount, penalty, previousOutstanding, totalReceivable, amountReceived ]

receipts table avec les colonnes suivantes [ id, loan_payments.id (FK), paymentAmount, otherPaymentDetails]

Le flux de code est le suivant:

1. Lors de la création d'un nouveau prêt, nrInstallations les lignes sont entrées dans le tableau loan_payments pour ce client. En supposant sont fixés 10 versements pour tous les clients, 10 lignes seront créées
2. Pour la première ligne (installmentNo = 1), le penalty et previousOutstanding sera mis à 0.
3. Chaque fois qu'un nouveau paiement est reçu, le amountReceived est incrémenté de ce montant dans l'élément actuel (installmentNo = 1) et une entrée est effectuée dans le tableau payments. * A tout moment de donner il n'y a que UN tranche actuelle *
4. Lorsque son temps pour la prochaine tranche (installmentNo = 2), la [ totalReceivable - amountReceived ] du précédent opus est inséré dans le prochain épisode de (installmentNo = 2) previousOutstanding. Tous les paiements/acomptes précédents sont gelés. Et l'intimation est envoyée aux clients indiquant, installmentAmount, penalty et previousOutstanding à payer.
5. Maintenant tous les paiements seront reçus contre ce en cours versement (installmentNo = 2) et son montant sera augmenté chaque fois qu'un nouveau paiement est reçu.
6. Tous les calculs de pénalités seront effectués par rapport au en cours.

Actuellement nous ne fournissons pas la mise à jour/suppression des paiements qui ne font pas partie de la tranche actuelle . Tout fonctionnait correctement, jusqu'à ce que le client demande une fonction pour mettre à jour/supprimer les paiements précédents. Voici les problèmes que nous devrons faire face, si nous permettons la mise à jour/suppression des paiements précédents

• Supposons que tranche actuelle ne est 5, Si le paiement des mises à jour utilisateur avec versement n ° 2, tous les calculs de previousOutstanding et penalty sera se tromper. Cela n'a pas de sens puisque, des avertissements ont déjà été envoyés aux clients. Il existe de nombreux rapports utilisant actuellement les colonnes previousOutstanding et penalty.

Nos requêtes:

1. est-il un bon design pour stocker previousOutstanding et penalty dans la base de données? Ou devrait-il être calculé dans le code?
2. Comment redessiner la logique/base de données pour permettre ce qui suit.
   1. Prenez paiement contre TOUT installmentNo
   2. Permettre la mise à jour/suppression de tout paiement précédent
   3. de calcul de la pénalité flexible. (Prendre% de l'utilisateur si nécessaire)
   4. Possibilité de renoncer à une pénalité pour un client particulier pour un acompte particulierNon.
   5. Si possible, déclarez combien de pénalités a été annulée pour un client donné contre lequel. (Si cette exigence rend complexe la conception, nous pouvons le laissons tomber)

Answer 1

Une base de données de la comptabilité devrait être facile à vérifier, ce qui signifie qu'il est préférable de le faire append seule et ne modifiez pas les anciennes lignes . Si certaines colonnes contiennent des agrégats précalculés, dénormalisez-les en les déposant et placez-les dans une vue pour que vos rapports fonctionnent toujours. Les mailings que vous avez envoyés en utilisant des snapshots de valeurs agrégées doivent être stockés dans une autre table append-only, et puisque vous les définissez comme snapshots, ils ne deviendront pas inexacts.