您将如何在Azure表中存储联系人？

我的系统的每个用户都可以有联系人。每个联系人都有姓名、地址、电子邮件、电话等详细信息

您认为将此联系人存储在Azure表中是一个好主意吗？我担心的是：

• 如何搜索特定字段（如电子邮件或电话）
• 如何仅获取属于特定用户的联系人
• 如何按字段对联系人进行排序

---

我认为联系人可能是存储在表存储中的一个很好的候选者，但前提是您可以在拥有者上进行分区，并且永远不需要在多个拥有者之间进行搜索或聚合

一种可能的设计是：

• 将联系人作为分区键和行键的某个唯一字段与所属用户一起存储一次，但将字段作为每行中的列

如何搜索特定字段（如电子邮件或电话）

• 然后，您可以要求表存储在一个分区内进行搜索—然后它将在该分区内进行扫描—对于任何单个分区来说，该分区都不会特别大或太慢

如何仅获取属于特定用户的联系人

• 这只是一个仅按分区键进行的简单查询

如何按字段对联系人进行排序

• 表存储中的所有结果都按（partitionkey，rowkey）排序，因此要对用户的联系人进行排序，您需要查询所有联系人，然后在web或worker角色中对其进行排序

---

当然，其他设计是可能的-

e、 g.您可以将每个联系人存储在多个表中的多个行中-这将允许您在表存储中具有预先形成的排序顺序

e、 g.您可以为每个用户使用单独的表而不是单独的分区键-这样做的好处是，当您删除一个用户时，您可以删除属于该用户的整个表

---

---

注意。。。虽然可以为此使用表存储。。。事实上，我现在几乎总是回到SQLAzure——它的功能更强大，更可预测（IMO）。当团队提供二级索引时，我可能会尝试将其用于我的更多数据。

虽然这回答了问题的主要部分，但留下了很大一部分问题——性能。不要在你的物品里面搜索。Conditiser将它们序列化，直到您将它们反序列化回来，您才知道它们。按分区键搜索的速度与索引的速度一样快。。。记住这一点！我同意你需要注意性能，Anze-但不要同意“永远不要在你的对象内搜索”。假设每个分区的联系人数很小（例如。