Azure Tables，PartitionKeys和RowKeys功能

Question

所以刚刚开始使用Azure表 - 在他们之前没有和他们一起玩过，所以想要查看它们。

我的理解是，我应该将此视为对象存储，而不是数据库，这很酷。但我有点困惑的几点...

首先，如果我有一对多的对象关系，根对象的partitionkey应该是什么样子？例如，假设我有一个University对象，它对于Student对象是一对多对象，并且说Student对象对于Classes来说是一对多对象。对于新生来说，其分区密钥是否应该是“universityId”？或'universityId + studentId'？我在MSDN文档中读到RowKey应该是一个特定于我正在添加的项目的ID，这听起来也像studentId。

然后将一个新的大学partitionkey和rowkey都只是universityId？

我还读到，Azure表不用于存储列表 - 我认为它并不指向存储包含List ...的对象？

而且任何人都有使用asp mvc 3或4以及带有天蓝色表格的剃须刀的代码示例的任何链接？这是我的最终目标，很酷，看看什么人真的知道他们在做什么:)

谢谢！

Answer 1

绝对正确的是，Azure Tables比数据库更接近对象存储。你有一定的能力来查询非键列，并在查询中执行逻辑。但是您不应该计划将这些功能用于任何关键性能。

因为只有指定了至少一个严重影响表格布局的PartitionKey（最好是RowKey或范围或RowKeys），查询才会很快。您在开始时做出的决定稍后会对性能产生重大影响。作为一个粗略的比喻，我喜欢将它们看作一个SQL Server表，主键为（PartitionKey + RowKey），它永远不会有其他索引。这并不完全准确，但它会让你朝着正确的方向思考。

首先，如果我有一对多的对象关系，那么根对象的partitionkey应该是什么样的？

我可能会使用UniversityId作为PartitionKey。这通常是一个安全的地方开始。

对于新的学生，其分区键是否应该是'universityId'？或'universityId + studentId'？

你打算如何查询学生？如果你总是要有他们的UniversityId & StudentId，我可能会分别使它们成为PartitionKey和RowKey。如果你主要基于StudentId进行查询，那么我会将它用作PartitionKey。

新大学的partitionkey和rowkey都是universityId吗？

这是一个可行的选择。如果你真的没有别的东西放在那里，你也可以使用RowKey的常量值（例如“UNIVERSITY”）。

我还读到，Azure表不用于存储列表 - 我认为它不指向存储包含List ...的对象吗？

我不完全确定这意味着什么。显然你可以将一组对象存储在一个表中，这就是他们的用途。您不能直接在实体属性中存储列表。所以如果你的学生有一个类型为List的属性，那不能直接存储。但是您可以将其序列化为XML或二进制文件，并将其存储。

不幸的是，我没有任何代码示例。这可能是将您的数据逻辑抽象到其自己的层中的好时机，而不是将其放入您的MVC控制器中。我们发现一个抽象良好的数据层可以使你的逻辑单元测试变得非常简单。如果你为你的表创建了一些接口，那么使用List和一些LINQ创建模拟对象是非常容易的。