将复杂的嵌套SQL关联转换为可管理服务的前端数据建模最佳实践是什么？

Question

我正在寻求解决这个问题的可能解决方案.我将使用Angular和Rails,但实际上这个问题有点抽象,不需要在这些框架的上下文中回答.

在前端管理复杂嵌套SQL关联的最佳实践是什么？

假设您有帖子,评论和评论嵌套在帖子下.您将帖子作为JSON发送到前端,并在其下嵌套注释.现在你可以在每个帖子下面列出它们了,很棒.但随后出现了问题:

1. 如果您还想显示最近的评论怎么办？您的评论服务需要在规范化集合中进行评论,或者以允许按日期排序的方式访问它们.

   • 这是否意味着您对按日期排序的注释进行单独的API调用？这会在前端复制注释,并要求您在两个地方而不是一个地方更新它们(一个用于帖子,一个用于注释,假设可以编辑或更新注释).
   • 您是否实施了某种前端数据规范化？这意味着你有一个缓存层来保存嵌套数据,然后你将各个资源分配给它们相应的服务？

2. 如果您的数据具有不同的嵌套级别,该怎么办？继续发帖和评论示例.如果您的评论可以回复到10级,该怎么办？

   • 如果您对帖子和评论进行了单独的API调用,这会如何影响您的数据模型？
   • 如果您选择这种方法,这会如何影响您的缓存层？

3. 如果我们不只是在讨论帖子怎么办？如果您可以评论照片和其他资源怎么办？

   • 这对上面的数据建模模式的两个选项有何影响？

打破这个例子,如果我们谈论的是朋友之间的递归关系怎么办？

---

我最初的想法和假设的解决方案

我最初的想法以及我如何攻击它是使用缓存层并规范化数据,以便:

1. 缓存层处理任何必要的规范化
2. 缓存层保存每个记录的一个规范表示
3. 服务与缓存层通信以执行CRUD操作
4. 服务通常不关心也不需要知道数据模型的嵌套/复杂程度,当数据到达服务时它是标准化的

递归关系在某些时候需要是有限的,你不能只是永远地继续嵌套.

---

这当然听起来很棒,但我看到了很多潜在的陷阱,并希望获得观点.我发现很难将抽象的最佳实践从具体的解决方案分离到特定的数据模型.我很想知道其他人如何解决这个问题,以及他们将如何解决这个问题.

谢谢!

Answer 1

我假设你会使用restful api，注意我不了解rails，但我会建议你一些你可能会考虑的通用做法

假设您有一个页面显示 10 篇帖子以及按日期排序的 10 条评论，只需一次 api 调用即可实现此响应

还有一页仅显示 5 篇帖子，并且没有评论使用相同的 api 端点

通过一些查询参数可以实现这一点。

尝试尽可能优化您的响应。

您可以使用任何编程语言在一个端点中拥有多种响应类型，如果我们谈论 API，那就是我的工作方式。

如果您的查询需要很长时间，并且该查询运行多次，那么您当然需要缓存，但每个 api 调用中的 10 个帖子不需要缓存。它不应该对数据库造成困难。

对于嵌套问题，你可以有一个机制来实现它，即我将获取 10 个帖子及其所有评论，我可以发送一个查询参数，我想包含每个帖子的所有评论

像bar.com/api/v1/posts?include=comments

如果我只需要一些自定义数据作为他们的评论，我应该能够实现一些自定义包含。

像bar.com/api/v1/posts?include=recent_comments

你的API层，应该首先与你的自定义包含匹配，如果没有找到继续资源的关系

对于更深入的参考，例如comments.publisher或recent_comments.publisher，您的API层需要知道您当前正在处理哪个资源。对于正常包含，您不需要这个，但是自定义包含应该描述它们指向什么模型/资源，这样就可以创建无限链

我不了解 Rails，但如果您有强大的 ORM/ODM，您可以轻松实现此模式

有时，您也需要进行一些过滤，这项工作也同样如此。

您可以拥有过滤器查询参数并实现一些自定义过滤器

即 bar.com/api/v1/posts?include=recent_comments&filters=favorites

或者忘记一切，在
bar.com/api/v1/posts?transformation=PageA
下面创建一些内容 ，这将返回 10 个最近的帖子及其最近的 10 条评论
bar.com/api/v1/posts?transformation=PageB
这将只返回 10最近的帖子
bar.com/api/v1/posts?transformation=PageC
这将返回 10 个最近的帖子及其所有评论