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

Question

这里是场景：（MySQL 5.1+，PHP，Apache）

我正在计划一个 SaaS 应用程序，它可以让客户访问商店并预订 TRIPS。 （所有大写字母都是实体）。商店提供 TRIPS，但他们只有一定数量的员工来指导 TRIPS（交易记录）。本质上，这是一个根据可用员工数量管理每个商店的每日产能的问题。以产生最低开销的方式提供此功能的最佳数据库设计解决方案是什么？

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

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/ 创建一个巨大的汇总表（830,000 行），2/ 每年会被查询 1,000,000 多次（1000 家商店 * 每家商店 1000 次旅行）。当客户预订旅行时，它会增加数量（或者当旅行被取消时，数量会减少），这将有效地创建每日库存/容量。

那么，我的问题是：哪种方法最好？或者有没有更好的方法来做到这一点？

谢谢！

Answer 1

听起来很有趣！

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

但是，您确实需要一个“booked_trips”表来记录哪个员工预订了哪个旅行 - 您也可以将其存储在“trips”表中，但通常预订包含许多其他内容，例如发票、预订日期等，因此您可能需要将这些内容分开。

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

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

一般来说，我的建议是使用标准化方法并衡量性能；仅当您知道自己有问题时才进行非规范化。