php - 当需要配置控制时，我应该如何存储多个相关模型？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




我的问题:我计划在数据库中存储一个“项目”，其中一个项目由多个项目组成，例如文档，每个文档都有多个项目，例如段落。段落可以交叉引用其他文档中的段落。存在许多团队，每个团队可能有许多项目。团队成员编辑、更新和优化交叉引用文档的位置，直到他们满意为止，然后审查文档或项目。

发布文档时，经过审查，发布的状态将被保留，并且任何更改都会发生到新的暂存/当前状态。

项目发布时，对其进行整体审核和发布。然后在该问题中保留文档集、内容和交叉引用，以便在整个项目中捕获状态。然后将任何后续编辑应用到新的暂存/当前版本，使已发布的集合可供阅读，就像在发布时一样。

我曾考虑使用典型的数据库设置，但我担心 a) 存储的行数会迅速增加； b) 找到“当前”集合或任何特定项目的集合对于可靠使用来说过于复杂/脆弱。

作为变体，将文档存储在例如单个文档行中的 JSON 会阻止碎片化段落的传播，而不会导致性能大幅下降？

另一种想法是为每个项目分配一个 Git 存储库；但是然后担心存储和性能，并且不得不将“文档”存储为例如JSON 文件或类似文件，以便系统高效工作。然后，您最终还要为每个登录的用户管理每个 session 的暂存区，这会很慢 - 对吧？除了 GitHub，GitLab 等允许快速访问 repo 历史...

最初将通过 Web 应用程序访问数据库(或等效数据库)。最终，它可以通过 API 提供给本地客户端，或者甚至允许本地客户端使用 git 存储库，如果这是遵循的路径。理想情况下，将使用 PHP 或 NodeJS 易于访问的技术。

具体问题 - 如何/应该如何存储和访问需要配置控制的多个相关工件？

Answer 1

TL; 博士
您在此处公开的模型是关系数据库的一个非常清晰的用例。在数据库中存储文本没有显着的性能问题，如果你真的设法解决了数据库 io 瓶颈，现在服务器资源非常便宜，即使任何瓶颈几乎肯定会出现在你的代码中，而不是数据库操作中。

大纲
我将首先阐述为什么我认为事件溯源和 nosql 不合适的想法，然后漫谈一种对您所说的域进行建模的可能方法，并以一些如何进行任何操作的示例结束。
不是事件溯源
我首先想到了事件溯源，因为它可以轻松管理...事件的演变...例如编辑段落、审查问题等。
然而，在尝试对其进行建模时，这似乎不切实际，因为为了避免每次咨询问题时都必须重播整个事件链，您必须将快照保存在数据库/缓存系统中。支持问题的定时快照和事件溯源并不像是一场净胜。
不是 Nosql 数据库
我相信 nosql 数据库在这里实际上是一个明显的损失。你所说的一切都是完全、绝对的、关系性的。域的结构似乎永远不会改变，因此您不会从 nosql 灵活性中获益。
是关系数据库
因此，我认为这里应该完全首选传统的关系 sql 数据库设置。
我在处理相对大量的文本(非常像具有多个任意长段落的文档)方面有第一手经验，并且在行乘法方面没有任何问题。它们确实会成倍增加，尤其是在您跟踪历史记录的情况下，但这就是关系数据库的用途，用于处理大量数据行。
数据库的暂定模型
我认为这里提到的大多数实体都可以直接建模。直截了当，我的意思是有几个标准字段:
- ID
- parent_id(当实体是子实体时，例如段落)
- time_created:时间戳
- time_updated:时间戳
一些 dbms 在行更新时提供时间戳字段的自动更新

基于此，这可能是一个段落结构。请注意，状态在这里，很可能在 paragraph_revision 中。例如，支持在段落首次发布后对其进一步修订进行审查。或者甚至可能两者兼而有之，因为我们稍后会看到它的用途。
段落
- 段落ID
- 文档 ID
- created_at
- 状态(to_be_reviewed、in_review、review、rejected、varia)
- 顺序(也许，如果需要文档中的特定顺序)

但是这里要小心，因为这种情况有点棘手。由于我们希望获得所有更改及其作者的详细历史记录，因此段落的实际内容在另一个表中，链接到原始(单个)段落实体。注意只有一个 created_at时间戳值。在这种范式中，段落修订永远不会更新，而是创建新的修订。可以使用数据库触发器或其他技巧来执行此操作。
段落修订版
- 段落ID
- created_at
- 文本
- 标题(如果需要)
- 修订号
可能可以使用一个简单的基于整数的修订号
- 作者_id

段落引用可以保证另一个多对多关系表。要获得所有段落引用，您 select referenced_paragraph_id from paragraph_reference where paragraph_id = :id或通过切换列选择引用特定段落的所有段落。在这里，您可以引用一般段落或段落的特定修订，以免丢失历史记录。
段落引用
- 段落ID
- referenced_pa​​ragraph_id

问题似乎是一个项目，一个或多个文档，每个文档由一个或多个段落组成。基本上，一个 issue表，一个 issue_document表，链接到单个问题，以及 issue_paragraph表，包含特定 paragraph_revision ID，链接到这些 issue_document table 。可以删除文档表，因为所有段落都是文档的子级，但我更喜欢能够直接选择内容而不是从他们的子级中选择它们。
问题
- issue_id
- 时间戳

问题文档
- issue_id
- 文档 ID

问题段落
- 文档 ID
-paragraph_content_id

UUID 可能相关
这可能是对实体使用 uuid 而不是数字 id 的有效情况，特别是如果增长使得必须复制数据库或能够在将其发送到数据库之前创建有效实体时。
外键不是可选的
虽然不太复杂，但这是一个有点花哨的模式。外键不是一种选择。每个父 id 必须有一个外键，数据库完整性必须由数据库引擎强制执行，或者这个 将 变得脆弱。有了外键，像这样一个有点复杂的系统可以并且会随着时间的推移保持一致。
管理域操作
希望我给出的关于如何创建表的几个例子可以给出一般结构的概念，现在是一些具体的例子，说明它如何适用于您的不同用例。
创建项目
相当简单:在 project 中添加一行表，现在不需要任何其他操作。
创建段落
需要添加两行:一行将唯一标识 paragraph 中的段落。 , 一个包含在 paragraph_revision 中的内容.
更新段落
在 paragraph_revision 中添加了一行 table 。如果人们每 5 秒保存一次，则可能可以使用和更新单个条目，直到用户做出“我对这个修订版没问题”的操作。 (使其成为“不更新修订”规则的唯一异常(exception)。可以使用其他技巧，例如 temp_paragraph_revision 表。)
查看段落
选择 paragraph_revision 的最高编号修订版会让你看到要审查的当前版本。通过选择特定 paragraph_id 的所有内容，可以列出所有修订版本。 .设置审核后，状态会在 paragraph 中更新和 paragraph_revision表，可能会阻止进行任何修订，或者如果添加了修订则重置审查状态。
发布段落或项目
在问题表中创建一行，将文档链接到 issue_document 表中的该问题，链接 paragraph_revision s 到 issue_paragraph 中的这些文件 table 。这里可以做一个选择，就是在这个issue_paragraph中包含修改的实际内容。表，要特别确定段落内容在问题后不能更改，但如果使用永不更新修订的规则，则没有必要。
结论
虽然这看起来像是要预先创建很多表，但它们中的大多数都相当小，一个好的 UML 图可以消除对这些表的大部分犹豫。在这里使用连接，确保在这些连接中使用的列上保留索引。所有这些都可以在大多数 sql 发行版中实现，如果你熟悉 MariaDB 和 MySQL，或者如果你知道它的 postgres。