数据库设计:管理日常库存/能力的低开销解决方案？

Question

下面是场景：(MySQL 5.1+，PHP，Apache)

我正在计划一个SaaS应用程序，它将允许客户访问商店和预订旅行。(所有上限均为实体)。商店提供旅行，但他们只有一定数量的员工来指导旅行(交易记录)。从本质上讲，这是一个根据可用员工的数量来管理每个商店的每日容量的问题。以最低开销的方式交付此功能的最佳DB设计解决方案是什么？

以下是数据库实体的简化视图：

table.clients  
client_id (pk, ai)  

table.shops  
shop_id (pk, ai)  

table.employees  
employee_id (pk, ai)  
shop_id (fk)

table.trips  
trip_id (pk, ai)  
client_id (fk)  
shop_id (fk)
trip_date (date)

设想方案1

当用户想查看日历时，我可以对每次请求运行一个查询，例如：

SELECT COUNT(*), 
trips.trip_date, 
trips.shop_id
FROM trips
WHERE shop_id=1
GROUP BY trips.trip_date, trips.shop_id

设想2

创建一个每天都存储信息的汇总表，但是这种策略似乎与开销问题有关。例如，假设每365天就有1000家商店预订，和表应该存储未来两年(830天)的信息。看起来，这将创建一个巨大的汇总表(83万行)，每年2/被查询1,000,000+次数(1000家商店*每家商店1000次)。当客户预订了一次旅行时，它会增加次数(或者当旅行被取消时，次数会减少)，这将有效地创建每天的库存/容量。

所以，我的问题是：哪种方法最好？还是有更好的方法来实现这一点？

谢谢!

Answer 1

那一定很有意思!

首先，我知道您已经为我们提供了模式的简化版本，所以我假设在其他地方还有更多，但是您的" trips“表看起来是错误的--如果商店只有一个客户端，那么您不需要trips表中的客户机ID。

然而，您确实需要一个"booked_trips“表来记录哪个员工的旅行--您也可以将其存储在”旅行“表中，但通常情况下，预订有很多其他内容，比如发票、预订日期等，因此您可能想将这些东西分开。

我建议您使用类似于“选项1”的方法--使用查询来派生存储在规范化表中的数据，而不是选项2，后者实际上是对速度的反规范化。

在您的问题中定义“开销”是值得的--几乎所有这些设计问题都是用时间与速度进行权衡；如果开销指的是磁盘空间，则您得到的答案与“运行我的查询的时间”不同。

通常，我的建议是使用规范化的方法并衡量性能；只有当您知道自己有问题时，才会进行去normalized。