php - 查找表 : any better practice?

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

masters and slaves 表中的cat_id 将描述和区分这些类别。例如，cat_id 1 是 Admins 和 Members 等等。

我将插入:

1. admin id 进入列master_id 和成员id转化为slave_id列
2. 父页面id进入列master_id 和子页面id转化为slave_id列
3. 将类别 ID 发布到列中master_id 和页面 id 到slave_id列
4. 等等

但是我很确定我是否应该去做:

1. 这是一个很好的查询吗表练习或应该做很多创造更多比不同的查找表关系？
2. 如果我可以做这样的查找表这只是一个查找表对于所有人，我会产生什么后果有 future 吗？请问这个鞋底查找表将被过度填充我的网站内容何时增长？
3. 我想到的另一件事是 -标签系统不是查找表吗也是解决方案？

谢谢。

Answer 1

这听起来很像反模式 One True Lookup Table。谷歌一下!

这是我在不到 1 分钟内想到的坏事列表:

• 您将无法实现参照完整性
• 所有关系都必须是多对多或一对多
• 您将无法处理属性(100 quty of article_id=1 在 store_id=7 中售出)
• 您将只能处理单列键
• 表格会更大(因此平均速度更慢)
• 索引也会变大(因此平均变慢)
• 可能引起不必要的争用
• 优化器的统计数据会变得有偏差
• 数据库维护变得更加困难

我可以很容易地想出更多，但我认为这不是真正需要的 ;)

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

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