设计Windows Azure Tables数据库以存储复选框状态

Question

由于没有设计非关系型数据库（具体而言是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

鲍勃，也决定执行此程序，但不与Alice一起执行。因此，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商店存储此数据的好方法是什么？您将如何设计此数据库？而且，您将如何对数据进行分区（行键，分区键）？

Answer 1

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

其次，正确识别和构建分区键可以使检索更快。

第三，Azure表不必具有统一的结构。您可以在一个表中存储不同类型的数据，即使使用相同的分区键也是如此。这开辟了RDBMS无法实现的可能性。

那你打算如何检索数据呢？有什么用例？

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

• 将您的程序，执行和操作都放在同一个表中。
• 为每个时间单位创建一个新表，为每个表提供数万到数十万行，或者其他一些有意义的单位。 （对于我最近完成的一个项目，应用程序的事件日志每月使用一个表，每个表增长到大约100,000行。）
• 创建一个分区键，为每个分区提供数百到数千行。 （我们使用的时间为DateTimeOffset.MaxValue。当您在不使用分区键的情况下查询Azure表时，您会先看到最低的分区。这个每小时递减的方案意味着最近一小时的条目位于结果窗格的顶部在我们的Azure工具中。）
• 将您的行键结构化为人类可读的。请记住，他们需要在表格中独一无二。所以可能是像Procedure_Bob_ID12345_20140514-134630Z_unique这样的行键，其中唯一的是计数器或哈希值。
• 当您查询数据时，请拉回整个分区 - 记住，它只是几百行 - 并将结果过滤到内存中，速度更快。

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

要考虑的另一件事是在表中存储整个过程等。对象图。回到我们的日志记录示例，日志条目可能包含详细信息，因此我们只需在表中填充整个JSON块。 （我们通常在Azure云服务中检索它，因此网络吞吐量不是一个有意义的约束，因为同一区域内的Azure-to-Azure速度是每秒千兆位。）

Answer 2

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

根据程序中的步骤数量，您甚至可能不太关心如何跟踪步骤值（可能使用可通过按位运算符组合的整数或枚举？）请参阅 - Most common C# bitwise operations on enums

Answer 3

PK，RK和其他表属性的选择取决于您将如何使用数据，主导查询和应用程序行为。存储团队blob（http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx）针对常见场景提供了相关指导。