我在十字路口，我不知道该选择什么，请告诉我。
有一个数据库，其中包含商品表及其在单独表中的一些属性，或者更确切地说：
good (~2k Записей)
catalog (~50 записей)
form (4 записи)
type (~100 записей)
color (10 записей)
sostav (5 записей)
sizes (~200)
width (~50)
相应地，在这 11 个（包括链接<->表）表中的每一个表中都有第 N 个列数。所有表总共约有 150 个。
问题是如何最好地做到这一点：
- 6 个不同的查询，只有必要的 JOIN 和列（1 个用于选择产品，5 个用于显示过滤器）+ JOIN 和条件（如果选择了过滤器和/或排序）
- 来自包含所有 JOIN 和所有列的查询的存储过程，并在 PHP 中进一步处理所有这些混乱（在我看来，这根本不是最优的，但你永远不会知道）
- 1 查询临时表并从中进一步选择（仍然很长，因为完整查询本身需要 2 到 20 秒）+ 如果我没记错的话，将为每个打开的连接分别创建临时表。因此，20 个并发用户 - 20 个约 300k 行的临时表
- 创建一个表，其中包含所有 JOIN 的选择结果，并为传入表的所有 PK 和所需列上的索引创建一个复合 PK，并定期更新它。假设每小时/5 小时/天一次。
- 选项 4，但通过触发器更新数据（我还不知道它是否可能在触发器中），产品数据不经常更新，但一次更新很多并且每次都触发触发器...添加 1 个产品将其与 5 个相关联尺寸 - 6 个调用触发，至少... + 类型 + 颜色...（经理每天可以更改/添加 10-50 种产品）
- 什么是正常选项？
在任何情况下，所有查询中应该包含的最小 JOIN 集是：
goods - собственно, товары
catalogs - категории товаров (для проверки вкл/выкл)
size_type_1 - размеры (для проверки остатков)
另外，在每个请求中都会有一个计算в наличии/ нет в наличии+ HAVING 根据这个计算过滤器（应该只有实际数据）
这是摆在我面前的挑战。正如我可以描述的那样，这似乎是所有细节。我真的希望得到你的帮助:)
