这是不好的DynamoDB数据库架构吗？

问题描述

在观看了有关DynamoDB及其最佳实践的一些视频之后，我决定尝试一下。但是，我不禁感到自己正在做的事情可能是反模式。据我了解，最佳实践是利用尽可能少的表，同时还利用GSI进行一些“繁重的”工作。不幸的是，由于我们仍处于早期开发阶段，因此我正在使用一个实际上没有严格定义访问模式的用例。

我们可能会看到的一些早期访问模式是：

• 获取特定游戏的获胜次数：剪刀石头布，拳击等。[1快速查找]
• 检索用户拥有的硬币数量。 [1快速查找]
• 检索某人购买的所有物品（不在乎日期）。 [不确定吗？]
• 可能会检索与用户关联的所有属性（rps赢，彩盒赢，硬币等）。 [我真的不知道。]

此外，我们可能需要完成2个操作。例如，如果用户赢得特定游戏，则他们可能会收到“硬币”。实际上，我们需要将硬币添加到用户的“硬币”属性中，并更新其在游戏中的获胜次数。

您认为我应该重新考虑该策略吗？此外，我们可能会开始创建与各种游戏和每个单独的游戏相关的“日志”。

解决方法

在不完全了解应用程序访问模式的情况下设计DynamoDB数据模型 是反模式。

花时间定义您的实体（用户，游戏，订单等），它们之间的关系以及您的应用程序密钥访问模式。刚开始时，这可能会很艰苦，但是在使用DynamoDB时，做到这一点绝对至关重要。我们（或您或任何人）还能如何评估您是否正确使用了DDB？

当我第一次使用DDB时，我以与您描述的相似的方式进行处理。我曾经使用过SQL数据库，在那里我可以定义一些表并依靠SQL的魔力来支持我的访问模式，因为我逐渐了解了应用程序访问模式。我很快意识到如果我想使用DynamoDB，这将行不通！

相反，我是从应用程序的前端开始的。我在应用程序中绘制了不同的页面，并确定了应用程序中最重要的概念。当然，我可能没有涵盖应用程序中的 all 访问模式，但是练习肯定确定了我需要一个可用的应用程序所需的最小访问模式。

如果您需要快速构建应用程序原型以更好地了解acecss模式，请考虑使用您和您的团队已经掌握的技能。如果您已经了解了使用SQL数据库进行数据建模的方法，请立即使用。一旦对访问模式有了更好的了解，并确定您的应用程序可以从使用NoSQL数据库中受益，就可以随时重新访问DynamoDB。