Conseils de conception de base de données pour les frais et les paiements

Question

Voici la conception actuelle des frais de scolarité et de paiement que j'ai créés. Je suis juste un peu coincé en ce moment parce que je ne peux pas modéliser la table de paiement/transaction. Aussi, j'aimerais connaître vos pensées et vos commentaires avec mon design actuel. C'est la première fois que je vais créer une base de données pour les frais et les paiements.

tables principales de ma préoccupation sont schoolyearfee_lt, student_fee_lt et Payment

Je pense à l'aide de la table Payment pour stocker la somme de tous les frais sur lesquels seront divisés de façon à ce que délai de paiement était choisi (mensuel, trimestriel, annuel, comptant).

Disons, par exemple, Monthly a été choisi comme plan de paiement.

amountToPayPerMonth = (sumOfAllAssignedFees/paymentterm) - downpayment 

où 11 inserts du tableau amountToPayPerMonth-payment seront exécutés et 1 downpayment. 11 + 1 = 12 mois

Comment le marquer comme payé? Devrais-je utiliser un autre Transaction table?

Est-ce un bon design? Des pensées ou des conseils?

Merci.

Answer 1

quelques réflexions (personnelles) sur votre conception et votre question.

1- schoolyearfee_lt. Il semble 1-to-n avec fee_mt. Si je comprends bien les mêmes frais peuvent être appliqués pour plusieurs shoolyears, catégorie etc, mais le montant pour une taxe ne change pas. Cela signifie, par exemple, que chaque année au cours de laquelle les montants des frais changent, je devrais créer au moins une nouvelle cotisation et un peu d'argent. Je crois que quelque chose peut être examiné ici. Je pourrais par exemple déplacer certains de ses champs (schoolyear?) À la table fee_mt, et/ou je pourrais déplacer le montant de fee_mt à schoolyearfee_lt. Il y a aussi d'autres possibilités, à savoir faire un tableau fee_years_lt, où stocker l'année et le montant (et peut-être d'autres facteurs qui changent les frais) et ainsi de suite. Peut-être que vous pourriez faire certains de ces changements, peut-être aucun, dépend de votre conception et de vos exigences. Les questions peuvent être: le montant change-t-il par année (je crois que oui), gradelevel, feetype, feecategory ou pas? Vous voulez une redevance principale que vous voulez applicable pour toujours ou vos frais sont recréés chaque année à partir de zéro?

2- Paiement. Je l'appellerais exactement avec sa signification: payment_plan. J'ajouterais un champ payé, un champ payment_date et un field schoolyear (dans la conception actuelle).

3- Student_fee_lt et schoolyear. Dans la conception actuelle, il vaut mieux ajouter l'année aussi. Selon le mode, le fee_mt est géré (voir ci-dessus) je le mettrais aussi dans le PK. Déplacer l'année à la fee_mt, vous n'avez pas besoin. Est-ce que student_fee_lt est vraiment nécessaire (il semble que le résultat d'une requête + le champ date_effective)?

4- Formule de paiement. L'acompte et, par conséquent, la formule me sont un peu clairs. Est-ce une sorte de réduction pour chaque paiement que vous faites ou est-ce un montant fixe? Dans ce dernier, vous devriez revoir votre formule. Pourquoi 11 paiements?

5- Plan de paiement choisi stockage. Je voudrais avoir une table où stocker le plan de paiement choisi par l'étudiant (et d'autres données), cela ne devrait pas être student_fee_lt, car il stocke les frais uniques attribués pour chaque étudiant.