Question

我想知道在设计查找表时是否有更好的做法或任何原则。

我打算设计一个抽象查找表，它可以满足不同的情况。

例如，我将查询表称为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_id 1是管理员和成员等等。

我会插入：

admin id进入列 master_id和成员ID进入 slave_id列
父页面id进入列 master_id和子页面ID进入 slave_id列
将类别ID发布到列中 master_id和页面ID进入 slave_id列
等

但我确信无论我是否应该这样做：

这是一个很好的查找表练习或应该做很多创造更多比一个查找表不同关系？
如果我可以像查找表一样这只是一个查找表对所有人来说，我会有什么后果将来有什么？这个鞋底查找表将被填充当我的网站内容增长？
我想到的另一件事是 - 标签系统不是查找表解决方案呢？

感谢。

Answer 1

听起来非常像反模式 One True Lookup Table 。谷歌吧！

以下是我在不到1分钟内提出的不良事项清单：

您将无法强制执行参照完整性
所有关系必须多对多或一对多
您将无法处理属性（在store_id = 7中销售100件物品_id = 1）
您只能处理单列密钥
表格会更大（平均来说更慢）
索引也会更大（平均速度慢）
可能会导致不必要的争用
优化程序统计信息将会出现偏差
数据库维护变得更难

我可以轻松拿出更多，但我认为不是真的需要;）

当一个人没有太多的数据库经验时，感觉做一件好事，重用东西并使用“常见”结构，但数据库很少从中受益。

为您的人际关系使用单独的表格。最后，无论如何你都会这样做。

Answer 2

根据我的经验，最好为每个类别创建一个查找表。以下是我看到的好处：

一个查找表可能会变得非常大，而一些较小的查找表可能会被mysql的缓存机制加载到内存中，并且只有在您访问特殊类别时才能从那里处理。
更容易加载/重新加载/备份等一些较小的表格。
您可以稍后更改表格架构，假设您希望仅为一种类别添加其他字段。您无需将其添加到此全局表中的所有行。

我认为有一些小桌子而不是一张大桌子会有更多优点。

查找表：任何更好的做法？

2 个答案: