设计用于存储复选框状态的Windows Azure Tables数据库

由于没有设计非关系数据库（具体来说是Azure存储表）的经验，我很难想出一个好的设计来为我的应用程序存储数据

应用程序非常简单。它基本上是一个多用户待办事项列表：

User selects a "Procedure".
User gets presented with webpage with several checkboxes.
User starts checking checkboxes.
Each check/uncheck gets stored in the DB.

例如，假设我们有一个获取牛奶的程序：

Procedure 1 - How to obtain Milk:
    [_] Step 1 - Open fridge
    [_] Step 2 - Get Milk
    [_] Step 3 - Close fridge

Alice决定执行此过程，因此她创建了一个新的执行并开始选中复选框：

Procedure 1, Execution 1:
    Executor(s): Alice
    [X] Step 1 - Open fridge
    [X] Step 2 - Get Milk
    [_] Step 3 - Close fridge

Bob也决定执行此过程，但不能与Alice一起执行。因此，Bob创建了一个新的执行。另一方面，Charlie想帮助Bob，因此他没有创建新的执行，而是加入Bob的执行：

Procedure 1, Execution 2:
    Executor(s): Bob, Charlie
    [_] Step 1 - Open fridge
    [X] Step 2 - Get Milk
    [_] Step 3 - Close fridge

总之，我们可以有多个过程，每个过程可以有多个执行：

因此，我们需要一种存储过程的方法（复选框列表）；执行情况（谁、何时、复选框状态）；以及检查/取消检查的历史记录

这就是我到目前为止的想法：

• 创建三个表：过程、执行、操作
• “过程”表存储每个过程中的复选框
• Executions（执行）表存储谁和何时开始执行过程，以及复选框的状态
• 操作表存储每个复选框的选中和取消选中，包括谁和何时

我对这种方法不太满意，原因有很多。例如，每次用户单击复选框时，我们都需要更新Executions表行，同时在Actions表中插入新行。此外，我不确定这种设计是否能够扩展到大量的过程、执行和操作

---

使用Azure存储表或类似的NoSQL存储来存储这些数据的好方法是什么？你将如何着手设计这个数据库？另外，您将如何对数据进行分区（行键、分区键）？

根据使用方法，使用过程ID或过程ID ExecutionID的组合。不必担心构建准关系模型——只要根据在大多数情况下最有可能创建或使用数据的方式选择正确的分区键即可（即，从长远来看，您是否更关心程序、执行、受让人或步骤，以及您如何检索与单个实体相关的所有项目，例如在单个查询中检索程序？）

---

根据过程中的步骤数量，您甚至可能不太关心如何跟踪步骤值（可能使用整数或枚举，可以通过位运算符组合）请参阅-

根据使用方法，使用过程ID或过程ID ExecutionID的组合。不要担心构建准关系模型-只要根据大多数情况下最有可能创建或使用数据的方式选择正确的分区键即可（即，从长远来看，您是否更关心程序、执行、受让人或步骤，以及您如何检索与单个实体相关的所有项目，例如在单个查询中检索程序？）

---

根据过程中的步骤数量，您甚至可能不太关心如何跟踪步骤值（可能使用整数或枚举，可以通过位运算符组合）请参阅-

PK、RK和其他表属性的选择取决于您将如何使用数据、主要查询和应用程序行为。存储团队blob（）对于常见场景有此方面的指导。

PK、RK和其他表属性的选择取决于您将如何使用数据、主要查询和应用程序行为。存储团队blob（）有针对常见场景的指南。

首先，您不需要将Azure表强制转换为关系结构。它们速度非常快，价格非常便宜，设计为可以在检索时转储数据块并担心结构

第二，正确识别和构造分区键可以加快检索速度

第三，Azure表不必具有统一的结构。即使使用相同的分区键，您也可以在一个表中存储不同类型的数据。这为RDBMS提供了不可用的可能性

那么，您计划如何检索数据？用例是什么

假设您的主要用例是按时间检索数据，如审计日志。在这种情况下，我建议使用以下方法：

• 将您的过程、执行和操作都放在同一个表中
• 为每个时间单位创建一个新表，每个表可以提供数万到数十万行，或者其他有意义的单位（对于我最近完成的一个项目，应用程序的事件日志每月使用一个表，每个表增加到100000行左右）
• 创建一个分区键，为每个分区提供数百到数千行。（我们使用直到

  DateTimeOffset.MaxValue

  为止的剩余小时数。当您在不使用分区键的情况下查询Azure表时，首先会看到最低的分区。此按小时递减方案意味着最近一小时的条目位于Azure工具的结果窗格顶部。）
• 将行键的结构设置为可读。记住它们在表中必须是唯一的。因此，像

  Procedure\u Bob\u ID12345\u 20140514-134630Z\u unique这样的行键可能会工作，其中unique是计数器或散列

• 当您查询数据时，请收回整个分区--记住，它只有几百行--并在内存中过滤结果，这样会更快

假设您有第二个用例，需要按用户名检索数据。简单：在同一个表中，添加第二行，该行包含相同的数据，但具有基于用户名的分区键（

bob\u execution\u 20140514

）

另一个需要考虑的是存储整个。