Restructuring of the vb.net data center charging system-Summary (1) combing the business and table structure, vb.net Charging System

Restructuring of the vb.net data center charging system-Summary (1) combing the business and table structure, vb.net Charging System

The Charging System of the IDC room has been in progress for some time. I have received a notification two days ago and want to spot check the IDC for reconstruction. I have also become one of them. Therefore, although the IDC room has been accepted, we have re-checked, debugged, and the entire document process again. After some guidance from Master, I have gained a lot. Further understanding of data center reconstruction.

(1) reorganize the business: Check out

In the IDC charging system, the Administrator has a checkout function to check the content for the operator.

Among them, there are card sales, card refund, income amount, etc., but no consumption amount.

This is because the operator is only a "manager" responsible for revenue and expenditure, and the real school income is the portion consumed by students.

For example, if you have handled a card and paid 100 yuan for it, you will be refunded the card after 20 yuan is spent and 80 yuan will be refunded to you, then the real income of the school is that 20 yuan. The operator is only responsible for this process, but is only responsible for operations. Therefore, it has nothing to do with the amount consumed by students.

Therefore, there is a consumption amount in the daily and weekly statements.

In this table, the amount consumed is the real income of the school. Although the recharge amount is large, students may be able to return the card at any time. This part is not the real income of the school.

This part is clarified, so the operator's checkout button and daily statement are not linked to the weekly statement.

(2) Table Structure

In my IDC billing, the card table and student table are merged into one table.

Obviously, if the relationship is based on entities, the card should be a table, and the student should be a table. This seems to be more in line with the three paradigm. Many people regard the three paradigm as an "undead magic weapon", which improves the simplicity and maintainability of data. Therefore, this system strictly follows the three paradigm. Although there is nothing wrong, I think it is still necessary to start from the actual business in actual application, that is, the specific analysis of the specific business.

In a strict E-R diagram, all the object relationships should be one-to-many, there is no many-to-many, if so, we need to extract another table. The one-to-one relationship can also be placed in a table, because a student strictly corresponds to a card, and vice versa. In addition, the number of student table fields and card table fields is not very large, and placing them in a table does not cause a large amount of data.

Put it in a table. I can operate on only one table to operate on all the information. This avoids the possibility of easily modifying student information and forgetting to modify the card table, resulting in information asymmetry. The operation efficiency is also greatly improved.

I think that in actual system design, we should think more about whether to adopt the "third paradigm" instead of blindly pursuing it.