浅谈浅蓝表存储中的表设计
我应该组织REST服务，以便使用azure发送消息。现在我对DB有意见了。我有三个表:用户，聊天，聊天信息。
- 用户包含登录、密码哈希、盐分等用户数据。
- 聊天包含分区密钥-用户登录、行键- chatId、nowInChat -用户来自聊天。
- 聊天消息包含分区键，它由userlogin_chatId_datetimeticks (zevis_8a70ff8d-c363-4eb4-8a51-f853fa113fa8 _634292263478068039)、rowkey - messageId、message、发件人- userLogin组成。
我看到了设计中的缺点，比如，如果您设想用户在一年前积极交流，现在不说话，其中一人想查看历史，那么我将不得不在一个星期的时间间隔内向服务器发送大量请求，比如请求数据。以少于今天的时间发送请求将是无效的，因为我们得到了整个故事。我们该如何改变桌子的设计？
回答 3
Stack Overflow用户
发布于 2016-03-29 21:27:57
因为Azure存储表不支持辅助索引，而且存储非常便宜，所以最好的选择是使用不同的分区和/或行键两次存储数据。来自蔚蓝存储表设计指南：
要解决缺少辅助索引的问题，可以使用不同的PartitionKey和RowKey值存储每个实体的多个副本。
Stack Overflow用户
发布于 2016-03-31 22:10:07
谢谢你的帖子，你这里有两种选择。设计变更最少的最简单的答案是在聊天表中包含一个StartTime和EndTime。虽然这些属性不会被索引，但我猜一旦您在UserID上进行筛选，就不会有多少行要扫描了。
第二个选项需要更多的工作，但更干净，就是使用Partition = UserID，Row Key = DateTimeTicks创建一个额外的表，实体属性将包含ChatID。这将使您能够在给定的日期/日期范围内由用户快速筛选。(这是上文提供的非正规化答复)。
希望这有助于您的设计进度。
Stack Overflow用户
发布于 2016-04-08 09:30:12
我将使用这些PK和RK值创建一个单独的表:分区Key = UserID，Row Key = DateTime.Max - DateTimeTicks
您还可以将ChatId附加到上面的行键的末尾。
这样，最近由用户进行的通信将始终处于顶部。因此，以后只需传入UserId和取计数即可查询表(即。如果您想从用户获得最新的聊天条目，请使用Count =1)。查询也将非常快，因为您对行键使用倒排滴答，蔚蓝表存储服务将对同一用户id的条目进行排序，以增加行键的字典顺序，同时始终将最新的聊天放在分区的顶部，因为它具有最小的倒排滴答值。
即使您在RowKey的末尾添加聊天Id (即。InvertedTicks_ChatId)排序顺序不会改变，无论聊天id如何，最新的对话都将位于顶部。
返回实体后，从DateTime.Max中减去倒排的滴答，以找到实际日期。
https://stackoverflow.com/questions/36246140
复制相似问题
腾讯云开发者
