我是自由职业者，现在正在开发我的某个游戏并尝试使用Azure表服务来记录我在Azure表中的用户移动。 游戏基于卡片。
流程是这样的：
许多用户（UserId）将在桌面上播放（TableId）。桌上的每个游戏都有一个独特的GameId。在每个游戏中，可能会有多个独特DealId交易。 同一个桌面上可以有多个交易与同一个gameId。此外，每个用户在一个游戏中也会有相同的DealId。
获胜者是在玩家有多次机会后决定的。
问题：
我可以将TableId作为PartitionKey，但我不确定为RowKey选择什么，因为TableId和RowKey（GameId / UserId / DealId）的组合在表中应该是唯一的。 我可以有以下条目：
TableId GameId DealId UserId时间戳 1 201 300 12345 1 201 300 12567
我可以做的就是创建4个Azure表，如下所示，但我做了很多重复;我也无法点击https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/#guidelines-for-table-design
中提到的点查询GameLogsByTableId - 这将把TableId作为PartitionKey，将GUID作为RowKey GameLogsByGameId - 这将GameId作为PartitionKey，GUID作为RowKey GameLogsByUserId - 这将UserId作为PartitionKey，GUID作为RowKey GameLogsByDealId - 这将有DealId作为PartitionKey和GUID作为RowKey
请问？
TableId，GameId，DealId和UserId的格式很长。
我想查询数据
答案 0 :(得分：2)
根据我对Azure Tables的了解，我相信您已走上正轨。
但是我想提一下某些事情：
您可以使用单个表存储所有数据
您并不需要使用单独的表来存储每种数据，尽管这种方法在逻辑上可以很好地分离数据。如果需要，您可以将它们存储在一个表中。如果你使用单表，因为这些ID（游戏，表格，用户和交易）是数字，我建议的是正确地为值添加前缀，以便您可以很好地识别它们。例如，在指定表示游戏ID的PartitionKey时，您可以使用G|作为前缀，以便您知道它是游戏ID，例如G|101。
使用0预填充您的Id值，使其等长字符串
您提到您的ID值为long。但PartitionKey值为string类型。我建议预先添加值，使它们长度相等。例如，将游戏ID存储为PartitionKey而不是将其存储为1，2，103等，并将其存储为00000000001，00000000002，{{ 1}}。这样，当您列出所有ID时，它们将按正确的顺序排序。如果没有预先添加，您将获得1,10,11,12 ...... 19,20的结果。
您将失去交易支持
由于您正在使用多个表（甚至是具有不同PartitionKeys的单个表），因此您将无法使用Azure表中的00000000103，并且所有插入都需要作为原子操作完成。由于每个操作都是网络调用并且可能会失败，因此您可能希望通过幂等后台进程执行此操作，该进程将继续尝试将数据插入到多个表中，直到成功为止。
我建议您根据其他值创建一个复合Entity Batch Transactions而不是RowKey的Guid
这更适用于更新方案。由于更新需要RowKey和PartitionKey，因此我建议使用RowKey作为其他值的组合创建。例如，如果您使用RowKey作为TableId的PartitionKey，我建议您使用其他值创建GameLogsByTableId，例如RowKey。这样，当您获得要更新的记录时，您将自动知道如何创建U|[UserId]|D|[DealId]|G|[GameId]而不是首先从表中获取数据。
分区扫描
我查看了您的查询要求，几乎所有这些都会导致RowKey。为避免这种情况，我建议保留更多重复的数据副本。例如，在查询要求中考虑＃3和＃4。在这种情况下，您需要扫描整个分区以便用户查找有关游戏ID和交易ID的信息。因此，请为表服务除了延续令牌之外的任何内容返回的情况做好准备。
答案 1 :(得分：0)
就个人而言，除非您有绝对大量的数据要求，否则我不会使用表存储。它会使你的工作比使用SQL数据库更难。您可以使用任何您喜欢的索引，具有关系完整性等等。唯一支持ATS的是它对大数据来说很便宜。