问题描述
我正在建立一个系统,例如电影数据库,该数据库将有关电影的数据存储在数据库中。假设基础看起来像这样:
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,则表示该行已被拒绝,因此必须通过服务事件过程将其删除。