AWS Amplify - AppSync 和多个 DynamoDB 表
AWS Amplify - AppSync & Multiple DynamoDB Tables
当initializing a new GraphQL backend via the Amplify CLI时，示例模式使用@model 注释定义了多种类型。例如...
type Blog @model {
id: ID!
name: String!
posts: [Post] @connection(name: "BlogPosts")
}
type Post @model {
id: ID!
title: String!
blog: Blog @connection(name: "BlogPosts")
comments: [Comment] @connection(name: "PostComments")
}
type Comment @model {
id: ID!
content: String
post: Post @connection(name: "PostComments")
}
推送时，这会导致创建多个 DynamoDB table（每个模型一个）。因此，在此示例中，创建了三个单独的 DynamoDB table（博客、帖子和评论）
在我们的例子中，我们有一个 Users 模型，我们将有二十个左右的小集合与用户相关联。当感觉这些小集合都属于单个 table.
中的用户对象时，我对必须管理 20 个不同的 DynamoDB table 感到不安
从我正在阅读的所有内容来看，AppSync 似乎鼓励使用多个 table。例如，下面来自 AWS AppSync 文档的屏幕截图中的 Note 特别指出博客评论应该在生产环境中进入单独的 table。
这与 DynamoDB documentation 中列出的最佳实践相矛盾：
You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table.
当使用 AppSync 时，每种类型都属于单独的 DynamoDB table 吗？
Is it truly the case that when using AppSync each type belongs in a separate DynamoDB table?
不，您可以使用单个 table 来存储您的服务所需的不同类型（或实体）。只要您对将在服务中使用的数据定义明确的访问模式，您就可以只使用一个 table。但是，这种方法可能有点不灵活，因为您必须事先考虑您的访问模式，并且将来可能很难添加新的访问模式。
目前无法利用 Amplify 中的 @model 指令来进行此类配置。您将必须手动创建 table，然后相应地为每个 Appsync 类型设置解析器 query/mutate。
这是一篇解释该方法的好文章：
From relational DB to single DynamoDB table: a step-by-step exploration
如您所述，DynamoDB 文档建议“大多数设计良好的应用程序只需要一个 table”。当开发人员随着时间的推移了解了他们的数据访问模式、确定了数据模型并具有需要优化的某些规模要求时，这对许多应用程序都是有效的。许多开发人员从第一天起就没有对他们的应用程序有这种程度的理解，或者不一定有相同的需求。此外，在关于单一 table 设计的演示文稿中提到的一些要点（例如存储成本与计算之间的权衡）可能会根据您的应用程序而主观。
当您正在构建一个新的应用程序或不知道您的数据访问模式时，使用单一 table 设计模式的好处会逐渐减少，而使用多个 tables 策略的好处要多得多灵活。
AWS amplify 是一个自以为是的客户端框架，为具有不同规模和复杂性的开发人员提供合理的默认值，因此它在以最基本的形式利用 @model 转换器时采用了多重 table 策略.随着需求的发展，您可以通过使用 Transformer 的其他功能（例如 @key (for creating single table indexes and composite keys) or even full text search & streaming from DynamoDB with @searchable.
来增强此设计
我们确实认识到，大型或成熟的应用程序可能会受益于单一 table 方法。从多个 table 到单个 table 可能是一次性“合并”操作，在原型设计阶段之后，并且开发人员已经理解了数据访问模式。实际上，并没有“一刀切”的方法，这就是为什么 Amplify 的 GraphQL Transformer 会根据您的应用程序在其发展过程中所处的阶段为您提供不同级别的灵活性。
正如 Luis 在另一个答案中提到的那样：AWS AppSync 确实支持独立于 GraphQL Transformer 生成模式的任何类型的 table 结构。即使您确实有多个 table，您也可以使用 schema design, nested resolvers, or even implementing Pipeline resolvers.
在单个客户端请求中轻松实现 GraphQL 关系模式
（此回复是在 Richard 的帮助下编辑的）
当initializing a new GraphQL backend via the Amplify CLI时，示例模式使用@model 注释定义了多种类型。例如...
type Blog @model {
id: ID!
name: String!
posts: [Post] @connection(name: "BlogPosts")
}
type Post @model {
id: ID!
title: String!
blog: Blog @connection(name: "BlogPosts")
comments: [Comment] @connection(name: "PostComments")
}
type Comment @model {
id: ID!
content: String
post: Post @connection(name: "PostComments")
}
推送时，这会导致创建多个 DynamoDB table（每个模型一个）。因此，在此示例中，创建了三个单独的 DynamoDB table（博客、帖子和评论）
在我们的例子中，我们有一个 Users 模型，我们将有二十个左右的小集合与用户相关联。当感觉这些小集合都属于单个 table.
从我正在阅读的所有内容来看，AppSync 似乎鼓励使用多个 table。例如，下面来自 AWS AppSync 文档的屏幕截图中的 Note 特别指出博客评论应该在生产环境中进入单独的 table。
这与 DynamoDB documentation 中列出的最佳实践相矛盾：
You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table.
当使用 AppSync 时，每种类型都属于单独的 DynamoDB table 吗？
Is it truly the case that when using AppSync each type belongs in a separate DynamoDB table?
不，您可以使用单个 table 来存储您的服务所需的不同类型（或实体）。只要您对将在服务中使用的数据定义明确的访问模式，您就可以只使用一个 table。但是，这种方法可能有点不灵活，因为您必须事先考虑您的访问模式，并且将来可能很难添加新的访问模式。
目前无法利用 Amplify 中的 @model 指令来进行此类配置。您将必须手动创建 table，然后相应地为每个 Appsync 类型设置解析器 query/mutate。
这是一篇解释该方法的好文章： From relational DB to single DynamoDB table: a step-by-step exploration
如您所述，DynamoDB 文档建议“大多数设计良好的应用程序只需要一个 table”。当开发人员随着时间的推移了解了他们的数据访问模式、确定了数据模型并具有需要优化的某些规模要求时，这对许多应用程序都是有效的。许多开发人员从第一天起就没有对他们的应用程序有这种程度的理解，或者不一定有相同的需求。此外，在关于单一 table 设计的演示文稿中提到的一些要点（例如存储成本与计算之间的权衡）可能会根据您的应用程序而主观。
当您正在构建一个新的应用程序或不知道您的数据访问模式时，使用单一 table 设计模式的好处会逐渐减少，而使用多个 tables 策略的好处要多得多灵活。
AWS amplify 是一个自以为是的客户端框架，为具有不同规模和复杂性的开发人员提供合理的默认值，因此它在以最基本的形式利用 @model 转换器时采用了多重 table 策略.随着需求的发展，您可以通过使用 Transformer 的其他功能（例如 @key (for creating single table indexes and composite keys) or even full text search & streaming from DynamoDB with @searchable.
来增强此设计我们确实认识到，大型或成熟的应用程序可能会受益于单一 table 方法。从多个 table 到单个 table 可能是一次性“合并”操作，在原型设计阶段之后，并且开发人员已经理解了数据访问模式。实际上，并没有“一刀切”的方法，这就是为什么 Amplify 的 GraphQL Transformer 会根据您的应用程序在其发展过程中所处的阶段为您提供不同级别的灵活性。
正如 Luis 在另一个答案中提到的那样：AWS AppSync 确实支持独立于 GraphQL Transformer 生成模式的任何类型的 table 结构。即使您确实有多个 table，您也可以使用 schema design, nested resolvers, or even implementing Pipeline resolvers.
在单个客户端请求中轻松实现 GraphQL 关系模式（此回复是在 Richard 的帮助下编辑的）