separate to prepare for future business expansion
it is recommended to separate
mainly depends on the form of your own business requirements, and makes a specific analysis of the specific situation
benefits of separation:
- is not a property of the user table itself
- separate, it is easier to control the change of amount (especially in distributed environment)
balances are best separated. If you put the balance in the user table, there is actually a lot of trouble, and there will be a lot of extra work in interface design and development.
when displaying a user's home page, for example, we need to remove the banlance information from the public page.
banlance should be independent here. Here's what I do. Please refer to
.
user_account userid,username,password,nickname...
user_info userid,city,wxopenid,company...
user_pocket userid,cash,points,type...
user_comment ...
user_collect ...
user_like ...
user_follow ...
through several splits, you can effectively control the space size of a single table to optimize the query efficiency and reduce the security risk. Why not use a join table query 1 / 1 at a time when querying
, and 1 / 2 is an easy thing for mysql
from the perspective of the domain model, the balance is not an attribute of the user itself. [user] depends on [balance], and [balance] is associated with [user], so it is more reasonable to store it separately. If the user's information changes due to a change in the balance, or if the user's balance is inaccessible after the user is deleted, this sounds problematic. And the user and the balance may have their own states.
this design method, in short, is the separation of the schema (user simple information table-> user details table).
if written in the same table:
:
:2020
if you separate two tables:
:id
:
this is only the most simple analysis and is easy to understand. A deeper analysis of how to design a database requires more scenarios and business requirements
if there is only one user balance field, it is recommended to put it in the user table. The balance is not a large field and there is no need to split it.
two basic requirements of database design:
- can fulfill the requirements
- ensures performance
look at business requirements. The balance is not a user attribute, but belongs to sensitive data. It is better to separate
paradigm and anti-paradigm need to look at business requirements.
this is a trade-off. If the balance is particularly important, for example, if it is related to money in some business scenarios and is very sensitive, it should be stored separately in the extended table. If it is only similar to the data in the user table, then put it in the user table.
< H2 > take it apart < / H2 >
disassemble while retaining the data of the user table as cached fields. The most recent record in the balance table should keep the user's id, occurrence time, operation symbol, generated amount, and balance after operation to improve reliability.
if the amount of the user table does not match the action table, there is an anomaly.
on the top floor.
< / H2 >