相关疑难解决方法(0)

我正在使用谷歌应用引擎并使用低leval java api访问Big Table.我正在构建一个包含4层的SAAS应用程序:

• 客户端Web浏览器
• RESTful资源层
• 业务层
• 数据访问层

我正在构建一个应用程序来帮助管理我的移动汽车细节公司(以及其他类似的公司).我必须代表这四个独立的概念,但不确定我目前的计划是否合适:

• 约会
• 订单项
• 发票
• 支付

预约: "预约"是指员工需要提供服务的地点和时间.

订单项: "订单项"是服务,费用或折扣及其相关信息.可能进入约会的订单项示例:

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

发票: "发票"是客户承诺支付的一个或多个订单项的记录.

付款: "付款"是付款的记录.

在本应用程序的先前实现中,生活更简单,我将所有这四个概念视为SQL数据库中的一个表:"约会".一个"约会"可以有多个订单项,多笔付款和一张发票.发票只是通过订单项和客户记录生成的电子邮件或打印件.

十分之九,这很好.当一个客户预约一辆或几辆车并自己付款时,一切都很棒.但是这个系统在很多条件下都不起作用.例如:

• 当一个客户预约了一个,但约会中途下雨导致细节设计者必须在第二天回来时,我需要两个约会,但只有一个订单项,一个发票和一个付款.
• 当一组办公室的客户都决定在同一天完成他们的汽车以获得折扣时,我需要一个预约,但需要多个发票和多个付款.
• 当一个客户通过一张支票支付两张约会时,我需要两次约会,但只需要一张发票和一张付款.

通过稍微捏造一些东西,我能够处理所有这些异常值.例如,如果细节设计者必须在第二天回来,我会在第二天再次预约,其中的一个项目表示"完成",费用为0美元.或者,如果我有一个客户通过一张支票支付两次预约的费用,我会在每次预约中分配支付记录.这样做的问题在于它为数据一致性创造了巨大的机会.数据一致性可能是一个严重的问题,尤其是涉及财务信息的案例,例如客户通过一张支票支付两次约会的第三个例子.付款必须与提供的商品和服务直接匹配,以便正确跟踪应收账款.

拟议结构:

下面是用于组织和存储该数据的标准化结构.也许是因为我缺乏经验,我非常重视数据规范化,因为它似乎是避免数据不一致错误的好方法.使用这种结构,可以通过一次操作完成对数据的更改,而无需担心更新其他表.但是,读取可能需要多次读取以及内存中的数据组织.我稍后会想到,如果存在性能问题,我可以在"约会"中添加一些非规范化字段,以便更快地查询,同时保持"安全"规范化结构的完整性.非规范化可能会减慢写入速度,

表:

Appointment
 start_time
 etc...

Invoice
 due_date
 etc...

Payment
 invoice_Key_List
 amount_paid
 etc...

Line_Item
 appointment_Key_List
 invoice_Key …

我正在构建一个管理应用程序,以帮助管理我的移动汽车细节公司(并希望其他人).我正在努力弄清楚如何建模一些数据.

这个问题与我发布的上一个问题有关,但我已经复制了以下相关信息: 数据库设计 - 谷歌应用引擎

在这个应用程序中,有"约会"和"行项目"的概念.

约会是指员工需要提供服务的地点和时间.

订单项是服务,费用或折扣及其相关信息.可能进入约会的订单项示例:

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...

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

一个更具体的问题是我正在使用谷歌应用引擎,如果我想查询一组约会及其相关的订单项,我必须首先查询约会集,然后再对该行进行第二次查询使用IN运算符测试是否有任何Line_Item的约会密钥落入从上一个查询返回的约会密钥集中的项目.如果我有超过30个密钥要求我对查询进行分片,则第二个查询将失败.我可以对数据进行非规范化以避免这种复杂而广泛的读取查询,并且我可能不得不在某种程度上反规范化,但我宁愿在适当的地方避免复杂性.

我的问题是这种情况通常是如何建模的？是否适合将订单项与多个约会配对,或者将每个约会的订单项拆分为单独的约会是正常的,例如"2天工作的上半部分"和"2天工作的下半部分" ".类似的成功应用如何做到这一点？在这种情况下,有哪些经验法则？哪些实施变得不那么成问题？

谢谢!