Article data table, should be stored uid or username
Article display page: Need to display username author, the author of the link need uid;
If only one is stored, each article needs to query the member table once to get another message;
If both types of information are stored, space is wasted; I saw a lot of CMS cases, there is no such storage;
In general, how to choose;
I think the two are more reasonable storage, but looked at a few CMS, only one of the storage;
It makes me confused.
Reply to discussion (solution)
Store UID
It is recommended to put the UID and then display the username according to the UID
It is recommended to put the UID and then display the username according to the UID
Isn't it better if both of them are saved? Sacrifice space and reduce overhead. Isn't it more reasonable?!
Reduce the query one time.
Is it just an associative query?
It is recommended to put the UID and then display the username according to the UID
Isn't it better if both of them are saved? Sacrifice space and reduce overhead. Isn't it more reasonable?!
Reduce the query one time.
If the username can change, then you have to change the number of tables.
The UID is not on the line, the associated query can be found username.
Two are too wasted, a bit redundant, not necessary.
UID plus an index, query once is not very expensive, more than you save a field much better, try not to use a table query, with two SQL separate socialize
It is recommended to put the UID and then display the username according to the UID
Isn't it better if both of them are saved? Sacrifice space and reduce overhead. Isn't it more reasonable?!
Reduce the query one time.
If the username can change, then you have to change the number of tables.
Username change less, performance consumption is short;
But do not save username:
Such as: The article List page, need to display username; A page of 30 articles, equivalent to query 30 times username;
Even using correlated queries is very performance-intensive.
Even the use of correlated queries is very performance-consuming???
It's just a thought you took for granted.
The relational database is designed in such a way that there is no overhead associated with relational databases (rather than waste)
Please take your tuition seriously. Database Paradigm
I feel as long as your username definition is non-repeatable, or storage username better, he reduced the operation of a query database, to a certain extent, improve the efficiency of the program
If username is a nickname that allows modification, then only the UID is stored.
If the login username is fixed, then the ID and name are saved.
Username should not be stored according to the relational paradigm.
And can be used in non-relational, such as Memcache, with Uid=>username to read.
Sometimes out of the display username, also need to show the points, grade those, or need to look up the table, so only the UID is enough to facilitate the expansion.