TL;博士

大纲

不是活动来源

我首先想到的是事件外包,因为它可以轻松地管理。。。事件。。。如编辑段落、评论问题等。

但是,在尝试对其进行建模时,这似乎并不实际,因为为了避免每次咨询问题时都必须重播整个事件链,您必须将快照保存在数据库/缓存系统中。同时支持问题的定时快照和事件源并不像是一个净胜利。

我相信nosql数据库在这里是一个明显的损失。你所说的一切都是完全的,绝对的,有关系的。域的结构似乎永远不会改变,所以您不会从NoSQL的灵活性中获益。

对关系数据库是

因此,我认为这里应该首选传统的关系型sql数据库设置。

我有处理大量文本的第一手经验(非常像有多个任意长的段落的文档),对行的乘法没有任何问题。它们确实是成倍增长的,特别是如果你跟踪历史,但是关系数据库就是这样 ,处理多行数据。

我认为这里提到的大多数实体都可以直接建模。直截了当地说,我的意思是有几个标准字段:

- id
- parent_id (when the entity is a child, such as paragraph)
- time_created: timestamp
- time_updated: timestamp 
    some dbms offer automatic updating of timestamp fields on update of the row

基于此,这可能是一个段落结构。注意,状态在这里,很可能在 paragraph_revision 例如,支持在一个段落首次发布后对其进行进一步修订的表。或者两者都有,我们稍后会看到这一点的用处。

paragraph
- paragraph_id
- document_id
- created_at
- status (to_be_reviewed, in_review, reviewed, rejected, varia)
- order (maybe, if a specific order within a document is desired)

内容 段落的另一个表中,链接到原始(单个)段落实体。注意,只有一个 created_at 时间戳值。在这个范例中,段落修改永远不会更新,新的修改会被创建。可以使用数据库触发器或其他技巧来实现这一点。

paragraph_revision
- paragraph_id
- created_at
- text
- title (if needed)
- revision_number
    possibly a simple integer based revision number can be used
- author_id

段落引用可以保证另一个多对多关系表。为了得到所有的段落参考,你 select referenced_paragraph_id from paragraph_reference where paragraph_id = :id

paragraph_reference
- paragraph_id
- referenced_paragraph_id

一个问题似乎是一个项目,一个或多个文档,每个文档由一个或多个段落组成。基本上,一个 issue 桌子,a issue_document 表,链接到单个问题,以及 issue_paragraph 表,包含特定 第四段修订 ID,链接到这些 发布文件

issue
- issue_id
- timestamp

issue_document
- issue_id
- document_id

issue_paragraph
- document_id
- paragraph_content_id

uuid可以是相关的

这可能是将uuid用于实体而不是数字id的有效情况,特别是当增长需要复制数据库或能够在将其发送到数据库之前创建有效的实体时。

外键不是可选的

虽然不太复杂,但这是一个有点花哨的模式。外键不是一个选项。每个父id都必须有外键,数据库完整性必须由数据库引擎强制执行,或者 变得脆弱。有了外键,像这样一个稍微复杂的系统可以并且将随着时间的推移保持一致。

管理域操作

创建项目

相当简单:在 project

创建段落

需要添加两行:一行将唯一标识 paragraph ,其中包含 第四段修订

更新段落

在 第四段修订 桌子。如果人们每5秒保存一个条目,那么可能只有一个条目可以使用和更新,直到用户执行“我同意这个修订”操作。(这是“不更新修订版”规则的唯一例外。可以使用其他技巧,例如 temp_paragraph_revision

审阅段落

选择编号最高的版本 paragraph_id . 设置审阅后,状态将在 段落 第四段修订 表,可能会阻止进行任何修订,或者在添加修订时重置审阅状态。

发布段落或项目

在“问题”表中创建一行,将文档链接到“问题”文档表中的该问题,链接 这些文件在 发布段落 桌子。有一个选择可以在这里做出,那就是在这里包括修订的实际内容 发布段落 表,以确保段落内容在问题后不能更改,但如果使用从不更新修订的规则,则不必这样做。

结论

虽然这看起来像是要预先创建的许多表,但其中大多数表都很小,一个好的UML图可以消除对这些表的大多数犹豫。这里使用了连接,请确保在这些连接中使用的列上保留索引。所有这些都可以在大多数sql发行版中实现,如果您熟悉MariaDB和MySQL,那么可以在postgres中实现。

我在想不同的方法-你可以用 Event Sourcing CQRS (命令查询职责分离)。

好处:

• 您可以重播历史记录中的每个更改,查看文档是如何生成的
• 对于当前版本-您可以始终保持具体对象的最新缓存,以便快速读取
• 如果您需要返回到某个版本的历史记录,只需找到最接近的标记版本,然后从该版本重播事件直到您的时间点

缺点:

• 不同的建筑风格,需要不同的思考

对于存储,我认为SQL不一定是个问题,因为您将存储相对较小的数据(仅限事件),对于缓存,您可以使用NoSQL/Redis/。。。无论对你有什么好处。

缩放比例

• 由于CQRS,很容易为带有复制的数据库提供只读/只读节点

编辑:还有一件事-这对应用程序的主要部分很好,其他部分(例如用户管理)不必遵循这一点。通常这种解决方案只适用于这样的特定目的,对于CRUD(或类似的东西)来说是没有意义的。

编辑:

• 一切都是事件,所以您需要一些事件存储(主要是小对象,比如(Person X在文档Z中添加了段落Y到位置A),我认为没有一个SQL数据库可以很好地解决这个问题,或者任何支持JSON数据的存储
• 然后将文档保存在标记/当前版本-这意味着一个文档将由多个段落/引用/团队组成。。。等等,所有这些都是根据历史记录
• • 将新事件记录到存储
  • 生成新快照(意味着将事件应用于最后一个快照)
  • 如果有引用,并且需要它们是双向的,那么也要更新它们

我不确定在数据库中存储大量的json或文档是否是正确的方法。我看到从数据库中获取json需要相当长的时间。在数据库中存储大量数据的另一点是迁移。在迁移或备份的情况下,资源利用率和迁移所需的时间可能会成为一个挑战。

不如使用一些内容管理系统,这些系统具有很多功能,如版本控制、存档、存储优化和可用性。我们在以前的项目中使用了Documentum,它满足了我们的所有需要。将文档存储在内容管理系统中,并将它们与项目(DB)链接,以维护层次化的审批流程。

这更多的是一个评论,而不是你正在寻找的答案,但不幸的是,我们对评论有字符限制:)