为这个连锁餐厅提供的这种特定类型的“优惠”设计一个数据库的最佳方法是什么？

Question

我正在努力在一个餐厅连锁店的移动应用程序中添加一些功能，使用的技术堆栈是用于Android的Java和用于后端的PHP + SQL。

到目前为止，我一直使用NoSQL，但是由于这个应用程序已经在生产&使用SQL，他们要求我继续使用相同的技术堆栈。

这家连锁店在该地区有9家分店，每家分店都有一顿“一盒五”的套餐，你可以从他们的菜单中选择任何五样东西，然后在“一盒五”的标题下订购，折扣价格要比单独订购的价格高。

现在的任务是跟踪每个客户订购的5件商品，以及他们从哪一家店订购的。每天晚上，Cron作业将确定哪一种组合中的5种东西当天订购最少，然后订购该特定组合的用户将获得另一张折扣优惠券。(他们还需要保存所有的旧记录，以便进行分析。)

我想的是：

将包含以下列的restaurant1_offerorder表-

下订单的用户的用户ID，

日期-命令日期，

item1，item2，item3，item4，item5 (五列)，它们将包含用户购买的食物的ids。

而且，由于每个分店预计每天至少会有700+‘5 in a box’餐订单，所以每天都会有一个restaurant1_offerorder_old表，其模式与restaurant1_offerorder相同，后者将包含所有旧订单数据。

每天晚上，Cron作业都会插入从restaurant1_offerorder到restaurant1_offerorder_old的所有记录

这样，数据库将为每家餐厅提供2张桌子(总共18张桌子，我觉得这是错误的方法)

现在,

问题1:

这是这个场景的正确数据库结构吗？而且，是否应该为每家餐厅建立一个单独的数据库来存储旧的订单数据，因为很快就会有大量的订单？还是把所有订单都放在一张桌子上选择*和今天的日期比较好？(考虑一下一年后的订单数量)

问题2:

(不执行。只是好奇，希望将来能证明数据库结构，并考虑到可伸缩性)

假设这个系统需要被放大，变成一个点菜应用程序，任何餐厅都可以在应用程序中列出自己，并且可以选择“一盒五餐”(从他们自己的菜单中选择)，那么为每家餐厅的“一盒五餐”订单创建一张新桌子和为他们的旧订单创建一张桌子是正确的方法吗？(考虑到餐馆数量和用户数量的增加，似乎是个坏主意)

Answer 1

restaurant1_offerorder表

这样你就需要为餐厅的每一家分店提供一张独立的桌子，这将使整个系统很难用大量的桌子来管理。使用完全相同结构的多个表是没有意义的。

阅读更多- 有大桌子还是多张桌子更好？

相反，您可以考虑将这些出口添加到另一个表中，并将每个出口的ID作为另一列添加到offerorder表中。这样，您就可以有一张表来管理所有门店的一个盒子订单中的五个。

每天晚上，Cron作业都会插入从restaurant1_offerorder到restaurant1_offerorder_old的所有记录

这不是必要的。每天向具有固定大小的所有整数列的表中插入少于10000行(我说是10000行，因为您提到有9个端口，条目超过700个/天)不会明显地减缓读取操作的速度(因为显然没有(M)在此表上发生的任何更新或删除操作，因此最小的碎片)。

但是，由于所有列都是外键，如果您更改了另一个表中任何实体的主键，则需要一些时间遍历offerorder表中的所有行并更改所有出现的ID。(我不确定这个现象，请纠正我错了)

不过，只有当外键设置为ON UPDATE CASCADE时才会发生这种情况。通过使用ON UPDATE RESTRICT，您可以避免发生这种情况。(您也可以将其设置为SET NULL或NO ACTION，但这将使旧数据变得无用)

阅读更多- 对于一个MySQL表，有多少行“太多”？，有百万行的数据库表和可以处理>5亿行的数据库

每天晚上，Cron作业将确定哪一种组合是当天排序最少的5件事物，以及订购该特定组合的用户。

cron作业的另一种选择可以是在每次插入时运行的TRIGGER，并在一天内不断地存储五项及其订单计数器的集合，还可以存储订购每组的用户ID。一天结束时，您只需选择使用最低计数订购该集的用户ID，并清空计数器表。

但是，请记住，使用触发器会为每个插入的订单增加轻微的开销(当服务器正在加载大量订单时，这可能会造成问题)，但在一天结束时计算将非常快。

阅读更多- Mysql触发器/事件与的比较

他们还需要保存所有的旧记录进行分析。

如果要执行的“分析”已经定义，则可能不需要存储所有旧数据。您可以每天计算分析结果，并且只存储每日结果。此外，在每个月底，您可以计算整个月的分析结果(使用前面存储的每日结果)，并删除该月份的每日分析数据。这也可以扩展到季度，半年，每年，所有时间等。然而，如果分析计算方法在未来发生变化，你可能不会留下太多旧的数据来重新计算。

假设这个系统需要被放大，变成一个点菜应用程序，任何餐馆都可以在这个应用程序上列出自己，并且可以选择“一盒五餐”(从他们自己的菜单中)。

如果继续使用问题中提到的多个表，那么很快就会有很多表要管理。您可能需要继续使用单个offerorder表选项。

此外，服务器上的负载也将随着餐馆、其网点和用户的增加而大幅增加。确保为可伸缩性(MySQL高可用性和可伸缩性)做好数据库服务器的准备，或者使用云服务提供商提供的解决方案。

我不是数据库设计方面的专家，所以我们欢迎并感谢审查！