当实体不是关系型的时，Dynamodb应该应用单表设计而不是多表设计吗
假设当前数据库主要有3个表。
分区密钥
管理员
-id（Pkey）、用户名、电子邮件、创建数据、更新数据
横幅
-id（Pkey）、isActive、createdAt、标题
新闻
-id（Pkey）、createdAt、isActive、title、message
上面的表都与其他表没有关系，将来需要更多的表（我想大部分表也与其他表没有关系）
根据aws文档
You should maintain as few tables as possible in a DynamoDB application.
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html
因此，我正在考虑是否需要将这三个表合并到一个表中。
从现在起，我应该开始使用单个表，还是继续为数据库使用多个表？如果使用单个表，我应该如何设计表模式？
共有1个答案
DynamoDB是一个非关系型数据库，因此您可以专门设计您的模式，使最常见和最重要的查询尽可能快速和廉价。您的数据结构是根据业务用例的特定要求量身定制的。
当为DynamoDB表设计数据模型时，您应该从数据的访问模式开始，这些模式反过来会通知它们之间的关系（或缺乏关系）。
帮助您入门的两个有趣的资源是从SQL到NoSQL和NoSQL Design for DynamoDB，这两个资源都是DynamoDB的AWS开发人员文档的一部分。
在您的具体示例中，基于您试图回答的问题（即用例
-
我正在试图找出设置实体图的最佳方法。我将基于下面的图像进行解释。 TBLParentCustomer：此表存储主要客户的信息，主要客户可以是企业或消费者。（使用查找表TBLCustomerType标识这些客户。） TBLChildCustomer：此表存储主客户下的客户。主要业务客户可以有授权员工和授权代表，主要消费客户可以有授权用户。（它们是使用查找表TBLCustomerType标识的。） T
-
问题内容： 有一个只有一列的表可以吗？我知道从技术上来讲这不是非法的，但是它被认为是糟糕的设计吗？ 编辑： 这里有一些例子： 您有一个带有50个有效美国州代码的表，但是您无需存储详细的州名。 电子邮件黑名单。 有人提到添加一个关键字段。以我的看法，这单列将是主键。 问题答案： 是的，以使表格效率最高的方式设计表格无疑是一个很好的设计。“不良RDBMS设计”通常以低效率为中心。 但是，我发现大多数单
-
我不确定这是否是问这个问题的正确地方。 我是dynamodb的新手，正在尝试创建一个小型web应用程序。我已经阅读了这里的最佳实践http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/BestPractices.html 我的桌子将是： 建筑物 租户（一栋建筑可以有尽可能多的租户，由楼层编号确定） 收件人（每个
-
假设应用程序的域模型应该从头开始构建，如下所述： 一个人可能住在一个地址。一个人可以拥有多辆车。 如果我必须首先设计数据库，我可能会提出以下数据库设计（规范化、级联等不应该在我的具体问题中起主要作用）。 我主要遵循标准设计概念（如本链接中所述http://db.grussell.org/section006.html). 正如您所见，地址表有一个外键指向person表，因为person-addre
-
我很难模拟这种情况。我在设计一个基于位置的优惠券系统。用户可以定义区域和优惠，然后将每个优惠关联到多个区域。此外，每个区域可以有多个优惠。所以zone和offer有很多对很多的关系。用户实体拥有这两个实体。只有在同一用户拥有区域和优惠的情况下，才能将它们关联起来。图表会很有帮助。多谢了。
-
问题内容： 简而言之： 在进行响应式网页设计时，应该使用一个还是多个样式表？ 详细： 在响应式设计中，您倾向于拥有一个CSS主体块，然后在到达某些断点时需要其他一点来调整布局。您可以采用以下两种方式之一来组织代码： 单一样式表 多个样式表 似乎使用一个样式表可以减少HTTP请求的数量，但是您将拥有一个较大的文件，其中包含某些客户端可能不会使用的代码。多个样式表似乎可以减小文件大小，但是您会有更多的