Performance 数据库设计：管理每日库存/容量的低开销解决方案？

以下是场景：（MySQL 5.1+，PHP，Apache）

我正在计划一个SaaS应用程序，它将允许客户访问商店和预订旅行。（所有CAP均为实体）。商店提供旅行，但他们只有一定数量的员工指导旅行（交易记录）。从本质上讲，这是一个根据可用员工数量管理每家店铺每日产能的问题。以产生最低开销的方式提供此功能的最佳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
当用户想要查看日历时，我可以为每个请求运行TRIPS查询，如：

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

情景2
创建一个汇总表，存储每天的信息，但这种策略似乎是噩梦般的开销问题。例如，假设每年有1000家店铺预订每365天1000次行程，并且该表应存储未来2年（830天）的信息。这似乎会1/创建一个巨大的汇总表（830000行），每年查询1000000多次（1000家店铺*每家店铺1000次）。当客户预订行程时，它将增加该数字（或取消行程时，该数字将减少），这将有效地创建每日库存/容量

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

谢谢

听起来很有趣

首先-我知道你给了我们一个简化的模式，所以我假设其他地方还有很多，但是你的“trips”表看起来是错误的-如果商店只有一个客户，你不需要trips表中的客户ID

然而，您确实需要一个“预订行程”表来记录哪些行程是预订给哪个员工的——您也可以将其存储在“行程”表中，但通常预订还有很多其他内容，如发票、预订日期等。因此，您可能需要将这些内容分开

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

在你的问题中定义“开销”是值得的——几乎所有这些设计问题都是以时间和速度为代价的；如果开销指的是磁盘空间，则得到的答案与“运行我的查询的时间”不同

---

一般来说，我的建议是采用规范化方法并衡量绩效；只有当你知道你有问题时才去规范化。

Neville K，这是一个非常简化的模式版本。ORM是指商店有很多次旅行，客户有很多次旅行，等等。。。涉及到几个M:M表，但它们似乎与如何最好地实现每日容量管理目标的问题无关。谢谢，干杯！Neville K也是，查询速度确实是我最关心的问题。如果有1000人同时运行查询，我不想创建一个不会扩展的慢猪。干杯