Tag: 预约

约会和订单项

我正在构建一个管理应用程序来帮助管理我的移动汽车细节公司（并希望其他人）。 我正在努力弄清楚如何建模一些数据。 这个问题与我发布的上一个问题有关，但我已经复制了以下相关信息： 数据库设计 – 谷歌应用程序引擎 在这个应用程序中，有“约会”和“行项目”的概念。 预约是指员工需要提供服务的地点和时间。 订单项是服务，费用或折扣及其相关信息。 可能进入约会的订单项示例： 名称：价格：佣金：时间估计详细资料，常规尺寸：160 75 3.5小时$ 10全部详情优惠券：-10 0 0小时Premium详情：220 110 4.5小时派生总数（不是专项）：$ 370 $ 185 8.0小时 在我之前的此应用程序实现中，行项目由一个约会包含。 这在大多数时候都很好，但有时会引起问题。 一个例子是如果一个约会因为下雨而中途中断，技术人员必须在第二天回来并完成。 这种情况需要对同一个订单项进行两次约会。 在这种情况下，我只是通过将第二个约会上的“行项目”设置为“完成”这样的内容来稍微捏造数据，然后成本为0美元。 在下一个版本中，我正在考虑启用行项目与多个约会匹配，表格结构如下所示： Appointment start_time etc… Line_Item appointment_Key_List name price etc… 这种结构的一个普遍问题是它很复杂，我甚至不确定它是否适合将一个订单项与多个约会相匹配。 如果行项目只能作为一个约会的一部分，那么我实际上只需在每个约会中放置一个行项目列表，当我得到约会时，我已经获得了行项目。 一个更具体的问题是我正在使用谷歌应用引擎，如果我想查询一组约会及其相关的订单项，我必须首先查询约会集，然后再对该行进行第二次查询使用IN运算符测试任何Line_Item的约会密钥是否属于从上一个查询返回的约会密钥集的项目。 如果我有超过30个密钥要求我对查询进行分片，则第二个查询将失败。 我可以对数据进行非规范化以避免这种复杂而广泛的读取查询，并且我可能不得不在某种程度上反规范化，但我宁愿在适当的地方避免复杂性。 我的问题是这种情况通常是如何建模的？ 是否适合将订单项与多个约会配对，或者将每个约会的订单项拆分为单独的约会是正常的，例如“2天工作的上半部分”和“2天工作的下半部分” “。 类似的成功应用如何做到这一点？ 在这种情况下有哪些经验法则？ 哪些实施变得不那么成问题？ 谢谢！