1

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

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

正如 Redux.js 文档中所表达的那样，出于各种原因使用 React，最好使用平坦、规范化的存储状态形状，我认为使用 Vue.js 也是如此。

  • 帖子有类别（m：m）
  • 帖子有标签 (m:m)
  • 帖子有评论 (1:m)
  • 帖子中有主题标签 (m:m) // 或用户创建主题标签

  • 帖子中有提及（m：m）//或用户创建用户提及

  • 用户喜欢帖子 (m:m)

  • 用户关注用户、帖子、帖子类别等 (m:m)
  • 用户最喜欢的帖子 (m:m)

等等

我将需要显示帖子提要及其所有其他实体的相关数据，如用户、评论、类别、标签。为此，就像有一个1:many关系一样，将这个关系的数据的 many 边保存在一侧（可以说是parent），即使它实际上是many-to-many，对于通常查询它们似乎没问题组成他们的父母，那就是帖子。但是，我还需要反向查询商店状态，例如，获取具有特定类别或标签的帖子。

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

我怎样才能相对容易和有效地实现这一点，例如对于1:many关系？

4

1 回答 1

0

根据您的最后评论。我将介绍我目前用于这种情况的数据结构：

标签

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

标记发布

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

邮政

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

我发现存储关系 id 的 M:M 的每一面都可能产生orphans。在双重位置管理这些 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 节点的数量。

https://reactjs.org/docs/optimizing-performance.html#virtualize-long-lists

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

我在这里尝试了几件事：

  • 加载部分数据集：文件内（非反应式）与内存中（在 Vuex 中加载）
  • 排序、分页、在文件中搜索和加载结果
于 2018-07-02T23:51:39.377 回答