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

我想知道是否有更好的做法或任何原则来设计一个查找表。查找表：有更好的做法吗？

我打算设计一个抽象查找表，它可以服务于许多不同的情况。

举例来说，我打电话给我的查找表为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

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

回答

相关问题