用户生成/编辑的内容以及管理员接受和历史记录架构

如何解决用户生成/编辑的内容以及管理员接受和历史记录架构

我正在建立一个系统，例如电影数据库，该数据库将有关电影的数据存储在数据库中。假设基础看起来像这样：

movies
- id
- title
- description
- premiere date

我希望用户能够添加新电影，但也可以编辑现有电影中的各个字段。更改必须显示在“管理员面板”中，管理员可以在其中接受适当的更改。

到目前为止，我已经提出了这种方法。

具有用户更改的表，该表具有与电影表完全相同的架构：

movies_user_changes
- id
- author_id
- movie_id
- title
- description
- premiere date
- accepted

如果用户添加电影，请填写所有字段。如果仅更改描述，请添加仅填充描述列的记录。当管理员接受更改时，请将accepted设置为1，如果不是新电影更改，则将更改后的记录复制到movies_edit_history，然后使用id = movie_id进行更新记录。

我还考虑过制作键值表。

movies_user_changes
- id
- user_id
- movie_id
- key
- value
- accepted

用户更改描述时，添加带有key - description和值的记录。当用户添加一些更改时，添加一些记录。但是，当用户要将新电影添加到数据库时，我不知道该怎么办。将其添加到具有字段accepted = 0的电影表中吗？这种方法似乎并不理想。

关于编辑历史记录，我想存储它以便于显示编辑历史记录，并在需要时还原更改。我想知道movies_edit_history表是否应该为每次更改包含一个新记录，或者如果它为一部电影有一个记录会更好，但是每个字段都包含带有更改数组的JSON，例如

{
  [
    'edit_id': 1,'user_id': 1,'value': 'description_edit',]
}

电影数据库将包含大约40-6万条记录，并且系统将包含大约5-15,000条（将来可能会更多），并定期添加并建议更改用户，因此更改数据库可能会迅速增长。

我应该如何解决这个问题？有没有人创建过这样的工作系统并可以建议我如何计划？

解决方法

根据我的理解，这里的主要问题实际上不是您的数据结构或数据库模型本身，而是如何有效地管理定期出现在系统中的大量更改。

我建议您查看Wikipedia的工作方式，或其他此类大型项目：https://en.wikipedia.org/wiki/Help:Editing

一些其他想法可能会有所帮助：

将数据库中的每一行标记为“新条目”或“已编辑”，以便于进行重新分类和分类
在用户界面中使用一些视觉指示器（例如颜色）会有所帮助
确保有足够的员工来接受更改或新条目，这可能是实际的瓶颈
如果多个用户同时编辑同一条目怎么办？

Rob更改了标题
已更改标题和描述
迈克更改了描述和首播日期

您想接受夏娃的头衔更改，但麦克的首映日期更改。在这种情况下，最好将所有更改单独列出，这样您便可以快速批准/删除所需的更改。

换句话说-不要存储每个用户（每个电影）的全局编辑，而是存储每个列值的单独更改，例如，像这样列出它们：

movie_id
timestamp_of_submitted_change
谁编辑过
field_name_changed
new_field_value
if_accepted
timestamp_accepted

上面的一些想法也许会有用。

我看不到拥有2张桌子的原因。

考虑下一个结构：

CREATE TABLE movies (id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,title VARCHAR(255) NOT NULL UNIQUE,description TEXT,premiere DATE NOT NULL,createdAt DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,createdBy INT,/* foreign key to users table */
                     state ENUM('not approved','approved','declined') NOT NULL DEFAULT 'not approved');

首次创建某些电影的行时，用户将填充除自动设置的createdAt和分配给state的{{1}}以外的所有列（当然这些列在用户界面中没有显示。）

在编辑某些电影的行时，复制当前行（某些当前行-这可能是“最后批准”或“最后批准”，甚至是“我创建的批准后加上未批准的最后批准”）为此电影创建后，新插入的行的状态设置为'not approved'，然后用户编辑该副本。

管理员检查新行，并用'not approved'或state更改其'approved'。

检索到行后，将显示状态为'declined'的后一行（由createdAt）。

可能存在某些服务事件过程，例如每天执行一次。它将删除被拒绝的行和没有被批准的足够旧的行（例如，一个月）。

当然，结构可能会有所不同。例如，您可能不创建'approved'列，而是添加state列并使approvedAt可为空。如果某行在createdAt中为NULL，则该行尚未得到批准。如果某行在approvedAt中为NULL，则表示该行已被拒绝，因此必须通过服务事件过程将其删除。