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,轉成值,當然實際上也是到後台查了一下