所以刚刚开始使用 Azure 表 - 之前没有玩过它们，所以想看看。
我的理解是，我应该将其视为对象存储，而不是数据库，这很酷。但我在几点上有点困惑......
首先，如果我有一对多的对象关系，那么根对象的 partitionkey 应该是什么样的？例如，假设我有一个 University 对象，它与 Student 对象是一对多的，而 Student 对象与 Classes 是一对多的。对于一个新学生，它的partitionkey应该是'universityId'吗？还是'universityId + studentId'？我在 msdn 文档中读到 RowKey 应该是特定于我要添加的项目的 id，这听起来也像 studentId。
那么新大学的分区键和行键都只是大学ID吗？
我还读到 Azure Tables 不是用于存储列表 - 我认为它不是指存储包含列表的对象......？
任何人都可以使用 asp mvc 3 或 4 以及带有 azure 表的 razor 的代码示例链接吗？这是我的最终目标，看看真正知道自己在做什么的人会很酷:)
谢谢！
Azure Tables 更接近对象存储而不是数据库，这绝对是正确的。您确实具有查询非键列以及在查询中执行逻辑的能力。但是您不应该计划将这些功能用于任何对性能至关重要的事情。
因为只有在您至少指定一个 PartitionKey（最好是 RowKey 或范围或 RowKeys）时，查询才会很快，这会严重影响您的表布局方式。您一开始做出的决定将对以后的性能产生重大影响。作为一个粗略的类比，我喜欢把它们想象成一个主键为 (PartitionKey + RowKey) 的 SQL Server 表，它永远不会有另一个索引。这并不完全准确，但它会让你朝着正确的方向思考。
首先，如果我有一对多的对象关系，那么根对象的 partitionkey 应该是什么样的？
我可能会使用 UniversityId 作为 PartitionKey。这通常是一个安全的起点。
对于一个新学生，它的partitionkey应该是'universityId'吗？还是'universityId + studentId'？
你打算如何询问学生？如果您总是要拥有他们的 UniversityId 和 StudentId，我可能会将它们分别设为 PartitionKey 和 RowKey。如果您主要基于 StudentId 进行查询，我会使用它作为 PartitionKey。
新大学的 partitionkey 和 rowkey 都只是 universityId 吗？
这是一个可行的选择。你也可以为 RowKey 使用一个常数值（例如“UNIVERSITY”），如果你真的没有其他东西可以放在那里。
我还读到 Azure Tables 不是用于存储列表 - 我认为它不是指存储包含列表的对象......？
我不完全确定这意味着什么。显然，您可以将对象集合存储在表中，这就是它们的用途。您不能直接将列表存储在实体属性中。因此，如果您的 Student 具有 typee List 的属性，则不能直接存储。但是您可以将其序列化为 XML 或二进制文件，然后将其存储。
不幸的是，我手边没有任何代码示例。这可能是将您的数据逻辑抽象到它自己的层的好时机，而不是把它放在您的 MVC 控制器中。我们发现，一个抽象的数据层可以让你的逻辑单元测试变得非常容易。如果为表创建一些接口，那么只使用 List 和一些 LINQ 就可以很容易地创建模拟对象。