构建多关系笔记或更新 table 的最佳方式是什么？
What's the best way to structure a Multi-relational notes or updates table?
首先，我知道这听起来像是一个主要基于意见的问题。但我真的不是要任何人提供不同的选择，而是以下哪一个是最好的。
What I want to know is out of the below options, which is considered the closest to best practice, and which is considered a clean approach?
Please note: I'm using php to handle information I/O so some options may require extra processing to complete a transaction.
问题
我在一家销售不同种类产品的公司工作，并且有多个我们想要跟踪的用户交互页面。
解决方案
我提出的解决方案是创建一个关系 table 来保存发生的所有更新。 IE。当一个新行被插入 table 时，另一行被插入 updates table 表明该项目是由 user_id 在 2015-11-20 13:05:34 上创建的 => 1。更改一行时，将在 updates table 中插入一个新行，其中包含日期和时间以及说明该行是上次修改的注释。为了创建这个解决方案，我将想法缩小为几个选项。
** 选项 1
创建一个名为 updates 的 table，每个类型的行都有一列，前缀为 _id，一个 user 列说明谁执行了操作，一个日期时间列和一个用于保存操作内容的列。结果看起来类似于：
+----+-------+-------+------------+-----------+----------+-----------+--------+
| id | time | user | action | design_id | image_id | upload_id | ..._id |
+----+-------+-------+------------+-----------+----------+-----------+--------+
| 1 | NOW() | 1 | "Deleted" | | 15 | | |
| 2 | NOW() | 10039 | "Created" | | | 50678 | |
| 3 | NOW() | 30845 | "Modified" | 11 | | | |
+----+-------+-------+------------+-----------+----------+-----------+--------+
然而，需要创建大约 15-20 *_id 的东西，每次我们添加一个功能时，我们都需要向这个 [=76] 添加另一个 *_id 列=].
** 选项 2
创建一个名为 updates 的 table，其中包含一个 referring_id 列和一个 type 列。基本上，type 将对应于操作发生的 table，而 referring_id 将对应于特定行。结果看起来类似于：
+----+-------+-------+------------+----------+--------------+
| id | time | user | action | type | referring_id |
+----+-------+-------+------------+----------+--------------+
| 1 | NOW() | 1 | "Deleted" | "image" | 15 |
| 2 | NOW() | 10039 | "Created" | "upload" | 50678 |
| 3 | NOW() | 30845 | "Modified" | "design" | 11 |
+----+-------+-------+------------+----------+--------------+
我认为这可能是最好的选择，因为在它到位后，不需要添加额外的列，而且看起来更容易阅读。
** 选项 3
创建一个名为 updates 的 table，没有任何关系 ID，只是用户 X 在特定时间 created/modified/deleted。将名为 update_ids 的列添加到每个 table 中，该列将包含 JSON 或 serializedArray 字符串，其中包含与 updates id 对应的 ID 数组 table。结果类似于：
Updates table
+----+-------+-------+------------+
| id | time | user | action |
+----+-------+-------+------------+
| 1 | NOW() | 1 | "Deleted" |
| 2 | NOW() | 10039 | "Created" |
| 3 | NOW() | 30845 | "Modified" |
+----+-------+-------+------------+
Images table
+----+-------+------------------------------------------------+-----------+
| id | user | filename | updates |
+----+-------+------------------------------------------------+-----------+
| 1 | 1 | "085c30fce08b794130fe83f6967e03c3c7ecab8e.jpg" | "[1]" |
| 2 | 10039 | "2387c0f43311c7bb2dc0c82c264d8ffaa09df570.png" | "[2]" |
| 3 | 30845 | "699ee87816bc9b253a864a999ff92e3c6f0696c5.svg" | "[3]" |
+----+-------+------------------------------------------------+-----------+
I sincerely appreciate any light you can shed on this subject.
选项1不受欢迎，不符合正常形式。
选项 2 是在这种情况下我会立即想到的选项，因为它正是我们所说的关系描述。但是，如果您需要频繁查询 updates table，那么查询可能会变慢。如果这会在遥远的将来某个时候发生，那么您将需要创建措施来使用 updates table，可能是缓存，或助手 tables。不要过早地优化它，但你应该知道，你需要优化它的时间迟早会到来。
选项3难查询。想象一下，当您想根据一小组用户 ID 查询 updates 时。这就是痛苦的定义。但是，如果您可以允许选项 3，因为您永远不需要做那样的事情，那么这也可能是可行的。
首先，我知道这听起来像是一个主要基于意见的问题。但我真的不是要任何人提供不同的选择，而是以下哪一个是最好的。
What I want to know is out of the below options, which is considered the closest to best practice, and which is considered a clean approach?
Please note: I'm using php to handle information I/O so some options may require extra processing to complete a transaction.
问题
我在一家销售不同种类产品的公司工作，并且有多个我们想要跟踪的用户交互页面。
解决方案
我提出的解决方案是创建一个关系 table 来保存发生的所有更新。 IE。当一个新行被插入 table 时，另一行被插入 updates table 表明该项目是由 user_id 在 2015-11-20 13:05:34 上创建的 => 1。更改一行时，将在 updates table 中插入一个新行，其中包含日期和时间以及说明该行是上次修改的注释。为了创建这个解决方案，我将想法缩小为几个选项。
** 选项 1
创建一个名为 updates 的 table，每个类型的行都有一列，前缀为 _id，一个 user 列说明谁执行了操作，一个日期时间列和一个用于保存操作内容的列。结果看起来类似于：
+----+-------+-------+------------+-----------+----------+-----------+--------+
| id | time | user | action | design_id | image_id | upload_id | ..._id |
+----+-------+-------+------------+-----------+----------+-----------+--------+
| 1 | NOW() | 1 | "Deleted" | | 15 | | |
| 2 | NOW() | 10039 | "Created" | | | 50678 | |
| 3 | NOW() | 30845 | "Modified" | 11 | | | |
+----+-------+-------+------------+-----------+----------+-----------+--------+
然而，需要创建大约 15-20 *_id 的东西，每次我们添加一个功能时，我们都需要向这个 [=76] 添加另一个 *_id 列=].
** 选项 2
创建一个名为 updates 的 table，其中包含一个 referring_id 列和一个 type 列。基本上，type 将对应于操作发生的 table，而 referring_id 将对应于特定行。结果看起来类似于：
+----+-------+-------+------------+----------+--------------+
| id | time | user | action | type | referring_id |
+----+-------+-------+------------+----------+--------------+
| 1 | NOW() | 1 | "Deleted" | "image" | 15 |
| 2 | NOW() | 10039 | "Created" | "upload" | 50678 |
| 3 | NOW() | 30845 | "Modified" | "design" | 11 |
+----+-------+-------+------------+----------+--------------+
我认为这可能是最好的选择，因为在它到位后，不需要添加额外的列，而且看起来更容易阅读。
** 选项 3
创建一个名为 updates 的 table，没有任何关系 ID，只是用户 X 在特定时间 created/modified/deleted。将名为 update_ids 的列添加到每个 table 中，该列将包含 JSON 或 serializedArray 字符串，其中包含与 updates id 对应的 ID 数组 table。结果类似于：
Updates table
+----+-------+-------+------------+
| id | time | user | action |
+----+-------+-------+------------+
| 1 | NOW() | 1 | "Deleted" |
| 2 | NOW() | 10039 | "Created" |
| 3 | NOW() | 30845 | "Modified" |
+----+-------+-------+------------+
Images table
+----+-------+------------------------------------------------+-----------+
| id | user | filename | updates |
+----+-------+------------------------------------------------+-----------+
| 1 | 1 | "085c30fce08b794130fe83f6967e03c3c7ecab8e.jpg" | "[1]" |
| 2 | 10039 | "2387c0f43311c7bb2dc0c82c264d8ffaa09df570.png" | "[2]" |
| 3 | 30845 | "699ee87816bc9b253a864a999ff92e3c6f0696c5.svg" | "[3]" |
+----+-------+------------------------------------------------+-----------+
I sincerely appreciate any light you can shed on this subject.
选项1不受欢迎，不符合正常形式。
选项 2 是在这种情况下我会立即想到的选项，因为它正是我们所说的关系描述。但是，如果您需要频繁查询 updates table，那么查询可能会变慢。如果这会在遥远的将来某个时候发生，那么您将需要创建措施来使用 updates table，可能是缓存，或助手 tables。不要过早地优化它，但你应该知道，你需要优化它的时间迟早会到来。
选项3难查询。想象一下，当您想根据一小组用户 ID 查询 updates 时。这就是痛苦的定义。但是，如果您可以允许选项 3，因为您永远不需要做那样的事情，那么这也可能是可行的。