查找表：有更好的做法嗎？

我想知道是否有更好的做法或任何原則來設計一個查找表。查找表：有更好的做法嗎？

我打算設計一個抽象查找表，它可以服務於許多不同的情況。

舉例來說，我打電話給我的查找表爲masters and slaves表，

CREATE TABLE IF NOT EXISTS `masters_slaves` (
    `mns_id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `master_id` varchar(255) DEFAULT NULL COMMENT 'user id or page id', 
    `slave_id` varchar(255) DEFAULT NULL COMMENT 'member id or user id or page id', 
    `cat_id` varchar(255) DEFAULT NULL COMMENT 'category id', 
    `mns_created` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00', 
    `mns_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 
    PRIMARY KEY (`mns_id`) 
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=3 ;

所以這種查找表可以服務器的這些類型等的關係，

Admins and Members 
Admins and Pages 
Admins and Posts 
Post Categories and Posts 
Page Parents and Pages 
etc

的cat_id在masters and slaves表會描述和區分這些類別。例如，cat_id1是管理員和成員等。

我會插入：

管理員ID爲 master_id和成員ID的列到 slave_id列
父頁面ID進入 master_id和子頁面ID列到 slave_id列
帖子分類id到列的master_id和頁面id到 slave_id列
等

但我相信這件事我是否應該去與否：

這是一個很好的查找表的做法還是應該做很多創造超過一個查詢表爲不同的關係？
如果我可以做像這樣的查找表，這只是一個查詢表所有人，我會未來有什麼後果？當我的網站內容增長時，這個唯一的查找表將超過填充的？
還有一點想到的是 - 不是標籤系統查找表的解決方案嗎？

謝謝。

來源

2011-03-19 laukok

嘗試使用百萬條記錄，發出查詢並查看會發生什麼。這應該暗示爲什麼你的想法不如聽起來那麼好:) – Furicane 2011-03-19 18:28:11

雖然我同意其他人的觀點，這個表格佈局通常是一個糟糕的主意，但表現並不像它看起來那麼大。索引和分區功能很好。 – Krab 2011-03-19 19:09:57

根據我的經驗，最好爲每個類別創建一個查找表。這裏有益處，因爲我看到他們：

一個查找表可能會變得非常大，而一些較小的查找表可以由MySQL的緩存機制被加載到內存中，如果你可以從那裏才處理正在訪問一個特殊的類別。
更容易加載/重新加載/備份等'一些小表。
稍後您可以更改表格模式，假設您希望僅爲一種類別的類別添加另一個字段。您不需要將其添加到此全局表中的所有行。

我認爲有更多的專業人士有一個小的表比一個大的。

來源

2011-03-19 18:29:38 aviv

這聽起來非常像反模式One True Lookup Table。去谷歌上查詢！

這是不好的事情列表我不到1分鐘，想出了：

您將無法實施參照完整性
所有關係都必須要麼多對一一對多或一對一許多
您將無法處理屬性（100數量的article_id的=在售1 STORE_ID = 7）
你只能對付單柱鍵
該表將更大（因此速度較慢平均）
該索引也將是較大的（因此速度較慢平均）
這可能會導致不必要的爭用
優化統計將變得歪斜
數據庫維護變得更難

我可以很容易拿出更多的，但我不認爲它真正需要的;）

當一個沒有太多經驗的數據庫，它的費用我很喜歡做一件好事，重用東西並使用「普通」結構，但數據庫很少從中受益。

爲您的關係使用單獨的表格。最後，無論如何你都會這樣做。

來源

2011-03-19 18:52:08 Ronnis

關於這個主題的博客文章http://www.simple-talk.com/community/blogs/philfactor/archive/2008/05/29/56525.aspx – 2011-03-19 18:54:46

查找表：有更好的做法嗎？

回答

相關問題