Database design - Simplified dictionary table [easy to understand]

Hello everyone , I meet you again , I'm your friend, Quan Jun .

   In database design , We often encounter various business needs , So as to design a variety of tables . And want to make a database , It not only requires a deep understanding of various business needs in the early stage , We also need to update and modify the database in the process of later project improvement, so as to make the database design more perfect .    For those tables that involve business, it may not be easy to start , But the various dictionaries that often appear in the project are a good place to start . The larger the project, the dictionary table is indispensable , Dictionary table is a common type 、 state 、 Some specific values such as units . Some people design a dictionary table for each business or module to identify types or states, etc , In this way, there will be a lot of watches . In fact, we can combine some dictionary tables , Using two tables can realize the functions of multiple tables . Let me demonstrate with three status tables .    Here are the contents of the three tables , The table names are Order_Status、Clip_Status、RedPacket_Status

   The functions of the above three tables are ： The first piece of status information used to process orders , The second one is for processing cards （ Such as membership card ） Status information , The third is the status information used to process red packets . According to the above situation, it is obvious that , The third table is redundant , It's completely possible to remove the third table and use the data of the second table , But because the business needs to add other statuses to the third table , Isn't it necessary to add this table , What if you add it to the second table ？ No way , If you need to maintain the dictionary table of each business module , There are two business modules corresponding to the second table , That would be a bit nondescript .    Next, the method of merging appears to be more flexible . We can assume that each business module is a large class , The dictionary table data used by the business module is assumed to be a small class . According to this idea, multiple dictionary tables can be merged .    The following figure shows the table structure ：

Table data ：

Linked table query results ：

Some people will say that the card status and red envelope status still have the same value ？ This is not good enough . It's simple , stay Functional_Describe Add a public area to the same value in the table . See the picture below ：

summary ： Obviously, this is a one to many relationship , A business or module corresponds to multiple states or types , This design can omit multiple tables , Scalability is also ok , For new businesses , Just go to Functional_Describe Add its description to the table , Going Status Add the corresponding dictionary table data to the table . It only involves data entry without adding tables .

Publisher ： Full stack programmer stack length , Reprint please indicate the source ：https://javaforall.cn/127084.html Link to the original text ：https://javaforall.cn