首先，我明白这听起来像一个主要基于意见的问题。但我真的不是要求任何人提供不同的选择，而是以下哪一种最好。
我想知道的是下面的选项，它被认为是最接近最佳实践的，并且被认为是一种干净的方法？
请注意：我正在使用php来处理信息I / O，因此某些选项可能需要额外的处理来完成交易。
我为一家销售各种产品的公司工作，并且有多个页面供我们想要跟踪的用户互动。
我提出的解决方案是创建一个关系表来保存所有发生的更新。即当新行插入表格时，另一行会插入updates表格，表明该项目是2015-11-20 13:05:34 user_id创建的1 =＆gt; updates。更改行时，会在updates表中插入一个新行，其中包含日期和时间以及说明它是上次修改的注释。为了创建这个解决方案，我已经将这个想法缩小为几个选项。
创建一个名为_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 | | | |
+----+-------+-------+------------+-----------+----------+-----------+--------+
列表示执行操作的人员，日期时间列，以及一个用于保存动作的列。结果看起来与此相似：
*_id但是，需要创建大约15-20 *_id的内容，每次添加功能时，我们都需要在此表中添加另一个updates列。
创建一个名为referring_id的表，其中包含type列，并附有type列。基本上，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 |
+----+-------+-------+------------+----------+--------------+
将对应于特定行。结果看起来与此相似：
updates我认为这可能是最好的选择，因为在它到位后，不需要添加额外的列，而且看起来更容易阅读。
创建一个名为X的表，其中没有任何关系id，只是用户update_ids在特定时间创建/修改/删除了某些内容。将名为id的列添加到每个将保存JSON或serializedArray字符串的表中，该字符串包含与updates表中的Updates对应的ID数组。结果与此类似：
+----+-------+-------+------------+
| id | time | user | action |
+----+-------+-------+------------+
| 1 | NOW() | 1 | "Deleted" |
| 2 | NOW() | 10039 | "Created" |
| 3 | NOW() | 30845 | "Modified" |
+----+-------+-------+------------+
表Images+----+-------+------------------------------------------------+-----------+
| id | user | filename | updates |
+----+-------+------------------------------------------------+-----------+
| 1 | 1 | "085c30fce08b794130fe83f6967e03c3c7ecab8e.jpg" | "[1]" |
| 2 | 10039 | "2387c0f43311c7bb2dc0c82c264d8ffaa09df570.png" | "[2]" |
| 3 | 30845 | "699ee87816bc9b253a864a999ff92e3c6f0696c5.svg" | "[3]" |
+----+-------+------------------------------------------------+-----------+
表SELECT * FROM Patient INNER JOIN Department ON
Patient.department_id=Department.id
where Patient.id<100;
我真诚地感谢您对此主题的任何启发。
答案 0 :(得分：1)
选项1 是不受欢迎的，与正常表格不符。
选项2 是我在这种情况下会立即考虑的选项，因为它是我们所说的确切关系描述。但是，如果您需要经常查询updates表，那么查询可能会变慢。如果这种情况将在遥远的未来发生，那么您将需要创建措施来处理updates表，可能是缓存或帮助程序表。不要过早地对其进行优化，但是你应该知道，当你需要对其进行优化时，迟早会有时间。
选项3 很难被查询。想象一下，当您想基于一小组用户ID查询updates时。这就是痛苦的定义。但是，如果你可以允许选项3，由于你永远不需要做那样的事情，那么这也是可行的。