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 就可以很容易地创建模拟对象。