3

在我的数据库中，我有不同的实体，如todos, events,discussions等。
每个实体都可以有tags, comments,files和其他相关项目。

现在我要设计这些表之间的关系，我想我必须从以下两种可能的解决方案中进行选择：

1. 分离的关系表

所以我将创建todos_tags, events_tags, discussions_tags, todos_comments, events_comments,discussions_comments等表。

2.常用关系表

我将只创建这些表：related_tags、related_comments、related_files等，其结构如下：

相关标签

  • entity(event|discussion|todo|etc. - 作为枚举或 tinyint (1|2|3|etc.))
  • entity_id
  • tag_id

我应该使用哪种设计？

可能你会说：视情况而定，我认为这是正确的。

我的情况大部分时间（可能 70%+）我只需要查询其中一个实体（事件、讨论或待办事项），但在某些情况下，我需要它们都在同一个查询中（包括事件、讨论、待办事项）例如具有指定的标签）。在这种情况下，如果我使用单独的关系表，我将不得不在 3+ 表上进行联合（在我的情况下它可以是 5+ 表）。

每个表中的行数不会超过 1000-2000 行（事件、讨论、待办事项）；

正确的方法是什么？对此有哪些个人经验？

4

2 回答 2

2

第二种模式更具可扩展性。通过这种方式，您将能够扩展您的应用程序以构建涉及一种以上类型的查询。此外，即使是动态地，也可以轻松地将新类型添加到未来。此外，它允许更大的聚合自由度，例如允许您计算每种类型中存在多少行，或者在特定时间范围内创建了多少行。

另一方面，第一种设计除了速度之外并没有真正的优势：但是 MySQL 已经擅长处理这些类型的查询，对您来说足够快。您可以创建一个索引“实体”以使其顺利运行。如果将来您需要对表进行分区以提高速度，您可以在以后进行。

于 2012-10-16T08:39:49.450 回答
2

拥有一个单一的、常见的关系表（例如 related_tags）是一种更简单的设计，您可以在其中指定列中的实体类型，而不是拥有多个表。只需确保将实体和 tag_id 字段正确索引在一起以获得最佳性能。

于 2012-10-16T08:44:34.120 回答