数据库设计-谷歌应用引擎

我正在使用googleappengine并使用低级javaapi访问大表。我正在构建一个具有4层的SAAS应用程序:

• 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数据库中的一个表:“约会”。一个“约会”可以有多个行项目、多个付款和一个发票。发票只是从行项目和客户记录生成的电子邮件或打印件。

• 当一位客户预约了一次,但预约中途下雨,导致服务人员第二天必须回来时,我需要两次预约,但只有一个商品、一张发票和一次付款。
• 当一个办公室里的一群客户为了打折都决定当天把车修好时,我需要一个预约,但需要多张发票和多笔付款。
• 当一个客户用一张支票支付两次预约的费用时,我需要两次预约,但只有一张发票和一次付款。

拟议结构:

下面是用于组织和存储这些数据的规范化结构。也许是因为我的经验不足,我非常重视数据规范化,因为这似乎是避免数据不一致性错误的一个很好的方法。使用这种结构,只需一个操作就可以更改数据,而不必担心更新其他表。然而,读取可能需要多次读取,再加上内存中的数据组织。我在后面想,如果有性能问题,我可以在“Appointment”中添加一些非规范化字段,以便在保持“safe”规范化结构完整的同时更快地进行查询。反规范化可能会降低写操作的速度,但是我认为我可以对其他资源进行异步调用,或者添加到任务中,这样客户机就不必等待额外的写操作来更新数据的反规范化部分。

Appointment
 start_time
 etc...

Invoice
 due_date
 etc...

Payment
 invoice_Key_List
 amount_paid
 etc...

Line_Item
 appointment_Key_List
 invoice_Key
 name
 price
 etc...

• 查询位于给定范围之间的“开始时间”字段的“约会”列表。
  • 将返回的约会中的每个键添加到列表中。
• 查询所有“行项目”谁的约会\u键\u列表字段包括任何返回的约会
  • 将所有行项目中的每个发票密钥添加到集合中。
• 查询发票集中的所有“发票”(这可以使用appengine在一个异步操作中完成)
• 查询所有“付款”谁的发票\密钥\列表字段包含与任何返回的发票匹配的密钥
• 在内存中重新组织,以便每个约会都反映为其安排的行项目、总价、总估计时间以及是否已付款的天气。

有人能对这个设计发表意见吗?这是我能想到的最好的,但我怀疑可能有更好的选择或完全不同的设计,我不认为这可能会更好地工作在一般或特别是在GAE(谷歌应用程序引擎)的优势,弱点和能力。

谢谢!

大多数应用程序都是读密集型的,有些则是写密集型的。下面,我将描述一个典型的用例和用户希望执行的分解操作:

• 阅读 -Manager加载日历并查找可用的时间
• 写 -经理向客户查询他们的信息,我认为这是一个连续的异步读取,因为经理输入每一条信息,如电话号码、姓名、电子邮件、地址等。。。或者,如果必要的话,在客户端应用程序收集了所有信息并提交之后,在最后写一篇文章。
• 写 -经理记下客户的信用卡信息,并将其作为单独的操作添加到他们的记录中

经理拨出电话:

• 管理器加载日历
• 经理为他想打电话的客户预约
• 写
• 阅读 呼叫服务器响应呼叫请求并读取CallRecord以了解如何处理呼叫
• 写 呼叫服务器将更新的信息写入CallRecord
• 当调用关闭时,调用服务器向服务器发出另一个请求以更新CallRecord资源(注意:此请求不是时间关键的)

接受答案: 前两位的回答都非常周到和受人赞赏。为了尽可能不完美地平衡他们的风险敞口,我以很少的票数接受了那个。