Database design experience sharing

 
 
MySQL
database design experience sharing
 
In fact, this experience sharing is not only for
MySQL
, the reason why this keyword is added is actually for search
engines to see, huh, huh. The goal of this article is to broaden the minds of newbies, and it may not be helpful for veterans.
 
The article mainly covers the following aspects:
 
1.
 
The meaning of data integrity constraints: the first line of defense for data;
 
2.
 
Avoid redundant fields: please do not think this is a manifestation of flexibility or flexibility;
 
3.
 
Please try your best to
 
4.
 
Why indexing: not just speed;
 
5.
 
Transactions, triggers and stored procedures: this is a door; the meaning of data
 
 
integrity constraints
 
Simple, throw in a bunch of fields and you're done, the script will do everything anyway.
However,
have you ever reflected on a problem? It is also a human being who writes the script. Humans will make mistakes. If they make mistakes,
they may mess up the
data, and data is the basis of all applications. Therefore, I suggest you to be quiet, careful, and spend more time
studying how to better design the database structure.
 
The primary key is a must.
 
This is my first suggestion.
Each table must have a primary key,
and it is best to use a separate field as the primary key,
which kills the possibility of two identical data from the root.
 
You may need additional unique keys
 
e.g. user info table,
In addition to the user number,
its login name should also be unique.
Don't expect
to . Do
it now.
Just mark it as a unique key.
Even if the program forgets to judge, it will not
make mistakes. data is stored.
 
The type and length of the field
 
Please try to use the type and appropriate length that matches the data. Although you can save the time as a
varchar
type,
it is obviously better to use the
datetime
type, because you can't store dates such as
2013-02-30 .
Save to a field of type
datetime . The length of the field also needs to be considered. Although too long is much less troublesome than too short, it wastes a lot of space. The default value is as far as possible to set the default value for the field. For example, the field is_read is used to indicate whether the user has read the message, 1 indicates read, please set a default value of 0 for it to indicate unread, not in future query statements Judging by is_read<> 1 or is_read = IS NULL OR is_read = 0 . allowed as





 

 













 

Is it NULL
?
 
This question requires thinking,
not allowing or not allowing such stereotyped judgments at all.
At the same time, it is
recommended not
to use
NULL
as a special value.
 
Foreign key constraints are essential
 
You must understand and start using foreign keys,
and understand the usage of foreign key constraints,
which is a very important part of maintaining data integrity
.
When establishing foreign keys, you will have a clearer understanding of the business logic of the program.
Correct use of it prevents accidental deletion
of data with dependencies, and at the same time ensures that no garbage is left during deletion through cascading deletion.
 
 
Avoid Redundant Fields
 
Don't think that redundant fields will make your data table more resilient and
flexible.
First of all, redundant fields must be
allowed to be
NULL
, because there is no suitable code to assign values ​​to these fields (if there are, it is not a redundant field,
right)
. This will only increase the size of the data table. In fact, it only takes a few minutes to modify the table structure, and the real trouble comes from
adding the corresponding business logic for the new fields.
 
And things are always changing.
Today you think you may use this field in the future,
but next week you may not
think so, and a month later you don’t remember leaving such a field at all. So, delete it.
 
 
Collect as much data as possible
 
In fact, this is a bit off topic, because it is not just a matter of database design, programmers may also spend some time.
My consistent opinion is that "data is the foundation of all applications"
, try to collect them as much as possible, it may be useful in the future (if
the application has a long-term vision, otherwise you can ignore this)
.
 
I can't imagine what
Google
, Baidu or Taobao will do tomorrow, but I'm sure their business adjustments are
based on these captured data.
 
Collecting data as much as possible means collecting some relevant information as much as possible without adding user operation instructions.
For example
, various times,
the trajectory of browsing pages, and so on.
I even suspect that in the future some apps will collect
information and use it to detect if an account has been stolen. In addition, I think you should try to do more things when
 
inserting
/
modifying
/ deleting data. Relatively speaking, these operations are less frequent and the amount of data in a single operation is smaller. Don't put all the stress on the query statement. For example, if your program needs to use a statement like SELECT *, SUM(`point`) AS `total_point` FROM `table` GROUP BY `user_id` , consider adding a total_point field to the table. Why build an index

 
 








 

 
If a field, or a group of fields, will appear in a frequently called
where
clause, they
should be indexed,
which will result in faster results.
At the same time, the purpose of unique indexes was mentioned earlier, use
them avoid accidents. I personally do not recommend using full-text indexing, especially for Chinese characters, the overhead of full-text indexing is
too high,
I would rather choose the in-site search function provided by the search engine.
Although the indexing of search engines is not very timely,
I
don't think it is unacceptable.
 
Again, I think you should try to do more things when inserting
/
modifying
/ deleting data, relatively speaking, these operations are less frequent and the amount of data in a single operation is smaller. Don't put all the stress on the query statement. Transactions, triggers and stored procedures , transaction processing is actually something to be done in the program. Multiple data operation statements should be placed in transaction processing. We need to pay attention to ensure the integrity of the data at any time. Triggers and stored procedures can reduce the number of SQL statements in the program and reduce the loss caused by the communication between the program and the database. In particular, triggers can help us a lot. We use them in the database design of this site. For example, when you post a reply or delete a reply, it will trigger an operation to update the number of replies in a document. However, due to


 
 

 





 




 






The quirks of cascading operations in MySQL databases that
don't make triggers fire may require you to do more processing to get the triggers to work smoothly.
 
 
Conclusion
 
Please carefully and carefully design your database,
and make table names and field names are easy to understand and avoid confusion.
For example
, the field that represents the deletion state is best named
trashed to
indicate deleted, not
trash
. Obviously, when you see the
value of
1
, you can understand that the former indicates that it has been deleted, and for the latter, you are afraid Not sure.
 
You can imagine that the database structure is a scale model of the software,
just like the model of a sales office,
it is only more beautiful than the
real thing , not uglier.
So if your database is not beautiful enough,
the quality of your software has basically been characterized as
unsightly .
 
If you have any comments or ideas, you can
click here to open the original address
and tell me by replying.
Only
registered users can reply. Ha ha.