Understand how mysql_ designs table structure elegantly

  Everyone knows the importance of data storage, and there is no need to emphasize it here. So how to effectively and reasonably store these data run by the software? In the design, you can refer to the following points:
   1. The design of the table structure should give priority to following the 3rd normal form
         . Why should you follow the 3rd normal form?
         The design that follows the 3rd normal form can make the data storage concise, clear, and the data will not have redundancy.

         The basic principles of 3 paradigms:
      a. Fields must be inseparable
      b. All fields must be completely dependent on the primary key, and it is absolutely not allowed to depend on part of the primary key, especially in the case of double primary keys
      c. Transitive dependencies are not allowed

           below . Give two examples that do not meet the paradigm:
              order details: [OrderDetail] (OrderID, ProductID, UnitPrice, Discount, Quantity, ProductName). Multiple products can be ordered in an order, so a single OrderID is not enough to become the primary key, the primary key should be (OrderID, ProductID). Obviously Discount (discount), Quantity (quantity) completely depends on (depends on) the primary key (OderID, ProductID), while UnitPrice, ProductName only depends on ProductID. So the OrderDetail table does not conform to 2NF

             Order table [Order] (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity) primary key is (OrderID), CustomerName, CustomerAddr, CustomerCity directly depends on CustomerID (non-primary key column), rather than directly on the primary key, it is through Transit depends on the primary key, so it does not conform to 3NF.

    2. Sometimes it can also be designed in an appropriate reverse paradigm.
    3. The primary key design in the case of a single database and a single table. Using the big int self-increment data type
          unordered primary key will cause frequent splitting of index pages and affect performance.
          If the primary key data type is too large, it will affect query performance, memory, bandwidth, and IO resources.
    4. The primary key design in the case of sub-database and sub-table should be reasonable. For
          detailed solutions, please refer to "My Understanding of Sub-database and Sub-table"
    5. The design of field type and field size should be reasonable
        mainly from disk storage, network bandwidth, and memory space saving , Reduce disk IO to consider.
    6. It is recommended that each table maintain the additional fields of create_id, create_time, update_id, and update_time
         to facilitate problem tracking in terms of data security; in the case of high concurrent operations, the optimistic locking mechanism can improve concurrency performance.