我正在构建一个管理应用程序来帮助管理我的移动汽车美容公司（希望还有其他公司）。我正在努力弄清楚如何对某些数据进行建模。

这个问题与我之前发布的问题相关，但我在下面转载了相关信息：数据库设计 - 谷歌应用引擎 https://stackoverflow.com/questions/3120192/database-design-google-app-engine

在此应用程序中，存在“约会”和“行项目”的概念。

预约是员工为了提供服务而需要到达的地点和时间。

行项目是服务、费用或折扣及其相关信息。可能进入约会的行项目示例：

Name:                          Price: Commission: Time estimate   
Full Detail, Regular Size:        160       75       3.5 hours 
$10 Off Full Detail Coupon:       -10        0         0 hours 
Premium Detail:                   220      110       4.5 hours 
Derived totals(not a line item): $370     $185       8.0 hours
  

在此应用程序的先前实现中，行项目包含在单个预约中。这在大多数情况下工作得很好，但有时会引起问题。举个例子，如果预约因下雨而中途中断，技术人员必须第二天回来完成工作。这种情况需要对同一行项目进行两次预约。在这种情况下，我会通过在第二次预约上设置“行项目”来读取诸如“完成”之类的内容来稍微捏造数据，然后成本将为 0 美元。

在下一版本中，我正在考虑使行项目与多个约会相匹配，其表结构如下所示：

Appointment
 start_time
 etc...

Line_Item
 appointment_Key_List
 name
 price
 etc...

这种结构的一个普遍问题是它很复杂，我什至不确定它是否适合将一个行项目与多个约会相匹配。如果行项目只能是一个约会的一部分，那么我实际上可以在每个约会中放入一个行项目列表，当我获得约会时，我已经获得了行项目。

一个更具体的问题是，我正在使用谷歌应用程序引擎，如果我想查询一组约会及其关联的行项目，我必须首先查询这组约会，然后对该行进行第二次查询items 使用 IN 运算符来测试 Line_Item 的任何约会键是否落入从先前查询返回的约会键集中。如果我有超过 30 个键要求我对查询进行分片，第二个查询将会失败。我可以对数据进行非规范化以避免这种复杂而广泛的读取查询，并且无论如何我可能都必须在某种程度上进行非规范化，但我宁愿在适当的情况下避免复杂性。

我的问题是这种情况通常是如何建模的？一个订单项与多个预约配对是否合适，或者简单地将订单项拆分为每个预约的单独项目是否正常，例如“两天工作的第一半”和“两天工作的第二半” ”。类似的成功应用程序是如何做到这一点的？在这种情况下，经验法则是什么？哪些实施结果证明问题较少？

Thanks!

您建议的方法效果很好；您可以将订单项的“appointment_Key_list”建模为列表属性，它将按您的预期工作。您不必使用 IN 运算符 - 这是为了将数据存储中的单个值与您拥有的键列表进行匹配（例如，“WHERE datastore_column IN ('a', 'b', 'c')），而您正在执行相反的操作 - 将单个值与数据存储中的列表进行匹配。

不过，我建议相反的做法可能更适合您的任务：让每个约会都有一个行项目键列表。其操作方式大致相同，但要检索约会的所有数据，您首先要获取约会，然后使用约会实体中的键对行项目进行批量获取。如果您知道约会的密钥，那么您就根本不需要进行任何查询。

我一直试图向 Pindatjuh 解释为什么查询列表属性的效率并不比单值属性低，但显然需要更详细的描述，所以言归正传，这里是......

App Engine 数据存储区索引简介

尽管 Python 和 Java 为数据存储提供了各种高级接口，但数据存储本身讲的是较低级抽象，称为实体。一个实体由以下部分组成：

1. 唯一的主键
2. （名称，值）对的列表

主键是您已经熟悉的数据存储区键。 （名称、值）对的列表是 App Engine 对实体中数据的表示。到目前为止就这么简单。具有以下值的实体：

a_string = "Hello, world"
an_int = 123

将被序列化为类似这样的内容：

[('a_string', 'Hello, world'), ('an_int', 123)]

但这如何与列表交互呢？嗯，列表被视为“多值”属性。也就是说，包含 n 个项目的列表存储为 n 个单独的属性。一个例子可能会让这一点更清楚：

a_string = "Hello, world"
an_int = 123
a_list_of_ints = [42, 314, 9]

将被序列化为：

[('a_string', 'Hello, world'), ('an_int', 123), ('a_list_of_ints', 42), ('a_list_of_ints', 314), ('a_list_of_ints', 9)]

正如您所看到的，该列表表示一系列值，所有值都具有相同的名称。当您从数据存储区加载数据时，SDK 会看到重复的值并将其转换为列表。

当它与索引交互时，这一点变得很重要。假设您在“a_string”和“an_int”上有一个索引。当您插入或修改一个值时，App Engine 会为其生成一组索引条目；对于上面的索引和上面的实体，它在索引中生成一行，如下所示：

('Hello, world', 123, a_key)

（这里的“a_key”是原始实体的键的占位符。）当您执行使用此索引的查询时，它只需要在索引上进行查找即可查找具有适当前缀的行（例如，“SELECT * FROM Kind WHERE a_string = "Hello, world" ORDER BY an_int')。

但是，当您为列表建立索引时，App Engine 会插入多个索引行。 'an_int' 和 'a_list_of_ints' 上的索引将为上述实体生成这些行：

(123, 42, a_key)
(123, 314, a_key)
(123, 9, a_key)

同样，查询的工作方式与以前相同 - App Engine 只需要在索引中查找具有正确前缀的行。列表中的条目数对查询速度没有影响，只影响生成和写入索引条目所需的时间。事实上，查询规划器不知道“a_list_of_ints”是一个多值属性 - 它只是将其视为任何其他索引条目。

简而言之：

1. 在索引和查询方面，包含一个元素的列表与单个属性之间没有实际区别
2. 索引列表的大小会影响索引所需的时间和空间，但不会影响查询所需的时间和空间。
3. 您可以使用简单的等式过滤器执行查询，以匹配列表中具有给定值的任何实体。