0

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

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

例如，我将查找表称为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是Admins 和 Members等等。

我将插入：

  1. 管理员 id 进入列， master_id成员 id 进入 slave_id列
  2. 父页面 id 进入列， master_id子页面 id 进入 slave_id列
  3. 将类别 ID 发布到列中master_id，将页面 ID 发布到 slave_id列中
  4. ETC

但我很确定我是否应该这样做：

  1. 这是一个很好的查找表实践还是应该为不同的关系创建多个查找表？
  2. 如果我可以做这样的查找表，它只是一个查找表，我将来会有什么后果？当我的网站内容增长时，这个唯一的查找表会被过度填充吗？
  3. 想到的另一件事是 - 标签系统不是查找表解决方案吗？

谢谢。

4

2 回答 2

4

这听起来很像反模式One True Lookup Table。去谷歌上查询！

以下是我在不到 1 分钟内想出的坏事清单：

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

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

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

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

于 2011-03-19T18:52:08.660 回答
1

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

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

我认为拥有几张小桌子比一张大桌子更有优势。

于 2011-03-19T18:29:38.547 回答