When we were born , What do we have ? Gender , date of birth , full name . What else is there but these ? weight , attribute , constellation , blood type , parent , brother , sister , Native place , ID number , other . These are all born .

Then we grow up slowly , Go to school , Enter the society and work hard , Working , Entrepreneurship and so on . We have a lot of information .


Draw a brain map , Maybe it's clearer :



So how to design the personnel table ? Look at that , Everyone has it all , basic , And what are the common ones ? full name , date of birth , Gender . These are the three . So I set up a basic personnel information table ——

Person_Info In addition to these three fields , Add primary key PersonID, ID number and record date added , Last modified date . This is the core table of personnel information .


Why do you do that ? Think about the ups and downs we've had , school ( Student information ), company ( Employee information ), hospital ( physical examination , Seek medical advice ), bank ( Apply for bank card , Credit Card ) etc. , No matter what the system is , These four fields are almost required , It's an important message that marks us , Its stability and versatility can be seen . Don't take this as the core , What is the core ?


When doing specific projects , We can set up other tables as needed , Like the educational information in the brain map , Work information, etc , Use both PersonID To connect . The purpose is to set up a stable table structure
. No matter how the demand changes , This table structure cannot be changed . This is the invariance in change . Look at the brain map above , Added a lot of extended information , But the personnel base table is still the core , It still works PersonID
As associated field . Added something , This structure has not changed . Is this stable and scalable ?


If you need , It's not on the top of the brain , Then you can try to add it , See if this structure is disrupted . If there's no disruption , It shows that the structure is stable , If you mess up , Could you tell me something, please ?


In member registration , I designed multiple tables , This is one of the reasons . In fact, the database is designed according to this idea .


Account information in the upper right corner , Added role part , This is a whim . Drawing brain pictures , Draw wherever you think of it , After drawing, I found that the structure was OK , No mess . So it was preserved . Account design , It is to realize that one person can have multiple login accounts , So set it to one to many , Then the table on the right side of the account information uses the primary key of the account information
UserID As an associated field .


Design in membership registration . I still think the brain map is easier to understand , ha-ha .

ER chart

Table diagram