That’s not the case. Suppose your article table is called the article table, where node_id and category_id are foreign keys, pointing to the node table and category table respectively.
Replace node_id with node_name and category_id with category_name as you said. Please think about a few questions:
If node_name or category_name needs to be updated in the future, will this field of the article table be updated?
And if you need to query the number of clicks on the nodes corresponding to articles that meet certain query conditions in the future, is it more efficient to query through node_id or node_name?
If the fields of the node table and the category table need to be expanded in the future, which one is better, the existing table structure or the modified table structure?
In fact, what worries you is that when querying the article table, you need to join the node table and the category table query. At this time, you can consider whether the article table needs redundancy of the node table node_name and the category fields of the category_name table. Although redundant fields will destroy the third normal form, appropriate redundant fields can improve query efficiency. This requires a business balance. Moreover, redundant fields also face the problem of how to maintain data consistency. For example, if the node field of the node_name table is updated, the article of the node_name table must also be updated.
Or you can also use views to solve this problem, and the method is more flexible.
CREATE OR REPLACE ALGORITHM=MERGE VIEW `v_article` AS (
SELECT a.id, a.title, ..., b.node_name, c.category_name FROM article AS a,
JOIN node AS b ON a.node_id = b.node_id
JOIN category AS c ON a.category_id = c.category_id
WHERE ... #如有需要,这里可以加上一些过滤条件
);
However, because the view uses the join table, sometimes the query efficiency may not be high. This requires more attention from the business and use EXPLAIN to analyze SQL.
That’s not the case.
Suppose your article table is called the
article
table, wherenode_id
andcategory_id
are foreign keys, pointing to thenode
table andcategory
table respectively.Replace
node_id
withnode_name
andcategory_id
withcategory_name
as you said. Please think about a few questions:If
node_name
orcategory_name
needs to be updated in the future, will this field of thearticle
table be updated?And if you need to query the number of clicks on the nodes corresponding to articles that meet certain query conditions in the future, is it more efficient to query through
node_id
ornode_name
?If the fields of the
node
table and thecategory
table need to be expanded in the future, which one is better, the existing table structure or the modified table structure?In fact, what worries you is that when querying the
article
table, you need to join thenode
table and thecategory
table query. At this time, you can consider whether thearticle
table needs redundancy of thenode
tablenode_name
and thecategory
fields of thecategory_name
table. Although redundant fields will destroy the third normal form, appropriate redundant fields can improve query efficiency. This requires a business balance.Moreover, redundant fields also face the problem of how to maintain data consistency. For example, if the
node
field of thenode_name
table is updated, thearticle
of thenode_name
table must also be updated.Or you can also use views to solve this problem, and the method is more flexible.
However, because the view uses the join table, sometimes the query efficiency may not be high. This requires more attention from the business and use
EXPLAIN
to analyze SQL.You can design a custom tag, and the page will directly convert the id into a value. Of course, you can actually check it in the background