Data Center reconstruction-why do we need to separate the card table from the student table and reconstruct it ---

Data Center reconstruction-why do we need to separate the card table from the student table and reconstruct it ---

During the reconstruction of the fee-based database in the IDC room, the previous Studetn_Info was divided into Card_Info and Student_Info. It is easy to know that it is used to decouple the students and cards, however, how to design the form and code can be used to embody the idea. I did not have my own opinions until I began to tap "register student information. (You are welcome to share your thoughts with us .)

First ,:

This page is the same as the previous version of the system. When you write code, you will find that when you click "save disk, "Student" and "card" are still"Bundling"Together, that is, adding a new card, whether it can correspond to multiple learning gods or whether it already has student information, they all need to re-write the student's related information (similar to "don't", "class "......), So I looked back at my database relationship diagram as follows:

I think if the interface does not change, it should correspond to the situations where the previous students and cards are not divided into two tables, and my design philosophy this time should be: first, add "Student Information" and then "card information ", when adding the card information, you can select or enter a student ID to implement the correspondence between the card table and the student table (StudentNo in Card_Info is a foreign key and two tables are connected ), in this way, the decoupling between the "card table" and "Student table" is realized. Just like in the above database graph, when adding a card, the Foreign Key is used to associate the two.

First look at the corresponding interface:

Registered student information:

Registration card information:

The following is a detailed analysis of why registration is divided into "registered student information" and "registration card information"

(1) In order to better reflect the separation of the "card table" and "Student table" in the database on the interface and code.

At first, it was very difficult to knock on the registration student information code when I didn't divide it into two interfaces. It can be said that the relationship was messy and the corresponding primary and Foreign keys were not properly understood. Although the database was set to two tables, however, it is not convenient to write the code before, or even consider more things. The two tables are more coupled.

 

(2) This prevents the previous "card" and "student" from being bundled for registration. If one person corresponds to multiple cards, the student information will be bound by selecting the student ID when adding the cards, instead of Repeated input.

 

(3) When the card is returned, back up the information in the card table to the "CancelCard" table and delete the card information corresponding to d in the "Card_Info" table when the card has been checked out, at the same time, the corresponding student information in the student table is retained. When you add the card again or activate the card, you can directly enter the previous student ID to bind the card again rather than re-enter the overall student information. (That is, the student information is dead, and the student information is established through registration and return cards)

 

To sum up, the registration information is divided into two forms for registration. The registration card information corresponds to the card table and the registered student corresponds to the student table. The two form a bridge through the Foreign Key in the Card_Info table, this design is similar to the design concept in the "bridge mode", making the cards and students more flexible than tied together.

 

The next blog will sort out and optimize the idea of "registration, recharge, and refund". The embodiment of this design will make my code logic clearer and simpler.

That is all.