客户端数据存储的规范化多对多模式

Question

我正在开发社交网络应用程序的浏览器前端。它有很多关系数据，具有一对多（1：m）和大多数多对多（m：m）的关系，如下表所示。

我想在应用程序中使用Flux数据流架构。我在Vue.js中使用Vuex.js.

正如在Redux.js文档中所表达的那样，最好为various reasons使用平坦的，标准化的存储状态形状以便与React一起使用，我认为这也适用于Vue.js。

等等

我需要显示帖子提要及其他实体的所有相关数据，如用户，评论，类别，标签。对于这个，就像拥有1：多关系一样，在一边保持这个关系数据的多方（可以说是父母），即使它实际上是多对多的，对于通常查询它们似乎还可以。撰写他们的父母，即帖子。但是，我还需要反向查询商店状态，例如，获取具有特定类别或标签的帖子。

在这种情况下，对帖子来说就不那么容易了。我需要一个关系实体，它保存两个连接数据实体的id对，就像RDBMS中的连接表或关联表一样，便于访问和更新，避免深入挖掘状态，同时避免不必要的重新渲染（要求是React或Vue.js和GUI特定的）。

如何相对容易和有效地实现这一目标，例如正如一个人所做的那样：很多关系？

Answer 1

根据你上次的评论。我将介绍我目前用于此情况的数据结构：

标签

{
 "type": "tag",
 "id": "tag1",
 "name": "Tag One"
}

标记发布

{
  "id": "someId",
  "type": "postTag",
  "tagId": "tag1",
  "postId": "post1"
}

岗位

{
 "id": "post1",
 "name": "Post 1"
}

我发现存储关系id的M：M的每一边都可能产生孤儿。在双重位置管理这些ID会导致复制步骤和认知管理的增加，因为管理M：M的所有功能都发生在两个地方而不是一个地方。此外，关系本身可能需要包含数据，这些数据将在何处进行？

M：M没有实体

{
 "id": "post1",
 "name": "Post 1"
 "tagIds": [
   {id: "tag1", extraAttribute: false} //this is awkward
 ] 
}

标记为发布 - 附加属性

{
  "id": "someId",
  "extraAttribute": false,
  "postId": "post1"
  "type": "postTag",
  "tagId": "tag1",
}

还有其他选项可以加速提取带有轻微弯头油脂的标签。

岗位

{
 "id": "post1",
 "name": "Post 1"
 "tagIds" : ["tag1", "tag4"]
}

假设一个帖子不会有超过20个标签。使这通常可忽略不计的存储要求，以减少查找。我发现目前没有迫切需要拥有10000个关系的数据库。

易于访问和更新

1：M是直接指向它想要的对象。 M：M是两个指向他们关系的不同实体。建立关系模型，并集中逻辑

重新呈现

如果您的应用程序呈现长数据列表（数百或数千行），我们建议使用称为“窗口化”的技术。此技术仅在任何给定时间呈现行的一小部分，并且可以显着减少重新呈现组件所花费的时间以及创建的DOM节点数。

我觉得解决方案可能是特定用例的，并且受到更广泛的意见。我使用带有Vuex的沙发/小袋和一个包含20,000个条目的非常大的表来讨论这个问题。同样，在生产中，问题并不是非常明显。结果总是会有所不同。

我在这里尝试几件事：