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 ... #如有需要,这里可以加上一些过滤条件
);
并不是这样的。
假设你的文章表叫
article
表,其中node_id
和category_id
是外键,分别指向node
表和category
表。按你所说的把
node_id
换成node_name
,category_id
换成category_name
,请思考一下几个问题:假如以后
node_name
或category_name
需要更新的话,那article
表的该字段是不是都要更新?而且如果以后需要查询满足一定查询条件的文章对应的节点(node)的点击数,是通过
node_id
查询效率高还是node_name
查询效率高?假如以后
node
表和category
表要扩展字段,是现有的表结构好还是修改后的表结构好?其实你烦恼的只是当查询
article
表的时候需要join上node
表和category
表查询,这时候你可以考虑article
表是否需要冗余node
表的node_name
和category
表的category_name
字段,冗余字段虽然会破坏第三范式,但适当的冗余字段可以提高查询效率,这个需要业务上平衡。而且冗余的字段还要面临如何保持数据一致性的问题,例如update了
node
表的node_name
字段的话,article
表的node_name
也要一并update。或者也可以采用视图的形式去解决这个问题,而且方式上比较灵活。
但由于视图使用了join表,所以有时候查询效率可能不高,这个需要业务上多加留意,多用
EXPLAIN
分析SQL。你可以设计个自定义标签,页面直接把id,转成值,当然实际也是到后台查了下