0

我的数据库有几个类别，我想将用户创作的文本“注释”附加到这些类别中。例如，名为 的高级表中的条目jobs可能有用户写的几条关于它的注释，但sub_projects. 由于这些笔记都是相同的格式，我想知道我是否可以通过只有一个笔记表而不是一系列表来简化事情job_notesor project_notes，然后使用多个多对多关系将其链接到几个其他表。

如果这不是从一开始就存在严重缺陷的想法（如果是，请告诉我！），我想知道最好的方法是什么。在我看来，我可以通过两种方式做到这一点：

  1. 每个更大的类别都有一个多对多的连接表，例如job_notes_mapping和project_notes_mapping，并单独管理 MtM 关系

  2. 将单个联结表链接到枚举或单独的表 for table_type，它指定 MtM 关系映射到的表：

    +-------------+-------------+---------------+
| note_id     | table_id    | table_type_id |
+-------------+-------------+---------------+ 
|           1 |           1 | jobs          |
|           2 |           2 | jobs          |
|           3 |           1 | project       |
|           4 |           2 | subproject    |
| ........... | ........... | ........      |
+-------------+-------------+---------------+

如果其中任何一个是完全可怕的想法，请原谅我，但我认为这至少在概念上可能是一个有趣的问题。

4

2 回答 2

1

理想的方式，IMO，将是拥有一个超类型的工作、项目和子项目——我们称之为活动——您可以在其上定义任何常见的事实类型。

例如（我假设工作、项目和子项目形成一个包含层次结构）：

activities (activity PK, activity_name, begin_date, ...)
jobs (job_activity PK/FK, ...)
projects (project_activity PK/FK, job_activity FK, ...)
subprojects (subproject_activity PK/FK, project_activity FK, ...)

不幸的是，大多数数据库模式为每个表定义了唯一的自动递增标识符，这使得在加载数据后实现超类型变得非常困难。PostgreSQL 允许序列被重用，这很好，其他一些 DBMS（如 MySQL）根本不让它变得容易。

我的第二个选择是您的选项 1，因为它允许定义外键约束。我根本不喜欢选项2。

于 2015-07-13T15:43:19.983 回答
0

不幸的是，我们最终得到了最丑陋的答案，即为每种不同类型的条目（job_notes、project_notes 和 subproject_notes）都有一个注释表。我们这样做的原因如下：

  • 具有包含联结“类型”列的单个联结表性能很差，因为没有一个外键是“真实的”并且必须手动搜索。注释字段包含每个条目的大量文本这一事实使情况更加复杂。

  • 每个条目的联结表比简单地为每种表类型具有单独的注释表增加了一个额外的表，虽然它看起来稍微漂亮一些，但它并没有带来实质性的性能提升。

我对这个答案不满意，因为为正在描述的每个作业/项目/子项目表有效地复制同一个 Notes 表似乎太浪费了。但是，我们还没有找到一个能够长期保持性能的答案。如果有人对如何执行此操作有更好的建议，我将保持打开状态！

于 2015-07-15T12:59:31.430 回答