Restructuring of the charging system for vb.net Data Center-Summary (1) Business and Table Structure

Restructuring of the charging system for vb.net Data Center-Summary (1) Business and Table Structure

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. <喎?http: www.bkjia.com kf ware vc " target="_blank" class="keylink"> VcD4KPHA + export/release + release/release + oo6yyotTawO/release + release/ew1jw6zl + dLUy/u6zdGnyfrP + release + pgltzybzcm9 "http://www.2cto.com/uploadfile/Collfiles/20150525/20150525094218208.jpg alt = "\">

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.

The 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.