学费处理的数据库设计

问题描述 投票:0回答:3

我需要有关数据库设计的建议。

我目前正在为一所学校设计 DBMS。设计完课程和考试表后,现在我来到了费用模块。

这是我到目前为止所做的。 我创建了 4 个表,描述如下:

fee_type
-------------
fee_type_id PRIMARY KEY

fee_type    TYPE OF FEE (MONTHLY, WEEKLY,ANNUAL,ONE TIME)

fees
-------------
fees_id PRIMARY KEY

fee_heading  (eg. TUITION FEE,LAB FEE, HOSTEL FEE,SPORTS FEE)

amount       (CURRENT CHARGE OF THE FEE, could change with time)   

class_id     (GRADE ID, GARDE 4, GARDE 5, GRADE 6)

fee_type    TYPE OF FEE (MONTHLY, WEEKLY,ANNUAL,ONE TIME)

archived     (FEE HEADING ARCHIVED FOR USE)

fee_student
-------------
fee_id     (RELATED fee_id (FK))

student_id (RELATED student_id(FK))

effective_from (DATE FROM WHEN THE FEE APPLIES TO THE STUDENT)

amount  (CHARGE AT THE TIME OF FEE ASSIGNMENT (applicable to particular student))

discount (DISCOUNT HONORED TO STUDENT IF ANY)

status (ACTIVE OR INACTIVE)

transaction
---------------
id PRIMARY KEY

date (date and time when transaction takes place)

fee_id (PAYMENT FOR)

student_id ({TO BE} PAID BY)

amount ( AMOUNT PAID/APPLIED)

description

cr ( yes or no)

dr (yes or no)

remarks

交易表将存储学生的所有付款以及对该学生收取的所有金额。

我正在考虑根据fee_type将向学生收取的金额存储在交易表中。这意味着,如果费用是每周类型,每周一条记录将自动添加到交易表中,并且金额被标记为借方(或贷方,等等)。

希望这是有道理的。

我设计数据库的道路正确吗?

我们将非常感谢您的意见和建议。

谢谢你

比什努

database-design relational-database rdbms database-schema
3个回答
1
投票

您的设计走在正确的轨道上。 一些评论:

  • fees.fee_type
    可能应该是
    fees.fee_type_id
    - 假设您想使用自然连接命名法。

  • 而不是

    transaction.cr
    transaction.dr
    ,您应该建立金额符号的约定,并且只有一个金额字段,该字段根据金额位于零的哪一侧被解释为贷方或借方。 您当前的设计允许金额同时为贷方和借方(除非您有禁止这样做的约束)。

  • 您的设计无法适应的一件事是“未使用的现金”。 在您当前的设计中,学生的付款必须针对特定的

    fee_student
    。 如果学生预付押金、获得奖学金或只是写一张支票支付多项费用(学费、实验室费用、体育费用)怎么办? 在您当前的模型中,您不会跟踪单笔(或未应用的)付款。 您应该有一个接受学生付款的交易表,然后使用交叉表(您当前的
    transaction
    表)将付款应用于特定费用。 这允许您拥有未付余额和未应用金额 - 这两者在现实世界的应付账款应用程序中都很常见。


0
投票

我认为您还应该在 Fee_student 中添加“费用到期日”列。

如果学校有 1 万名学生,您将如何为所有学生添加付费信息??????


0
投票

如果您需要详细跟踪,例如付款时间、支付金额以及保留多次付款的记录,那么创建单独的付款表将是一个更有效且可扩展的解决方案。

单独的表字段如下: payment_id Student_id(FK) amount_paid payment_date 状态等..

© www.soinside.com 2019 - 2024. All rights reserved.