我知道这有点具体,但我无法弄清楚如何让它变得更简单。它涉及多个连接和多个表。这给出了理想的结果,但是很丑陋。
这就是我所拥有的。有一个比所有这些连接更好的方法,特别是相同表的多个连接,但是每个其他变体花费太长时间来产生相同的结果。
SET @SEARCH:="toxic +crystal";
SELECT i.itemName item, id1.preview, it.isIngredient, it.hasRecipe, i2.itemName ingredient, id2.preview, it2.hasRecipe, ri.count AS needed, MATCH(i.itemName) AGAINST(@SEARCH) score
FROM recipe_detail rd
JOIN item_detail id1 ON id1.item_id = rd.output_item_id
JOIN recipe_ingredients ri ON ri.recipe_id = rd.recipe_id
JOIN item_detail id2 ON id2.item_id = ri.item_id
JOIN itemNames i ON i.itemId = id1.item_id
JOIN itemNames i2 ON i2.itemId = id2.item_id
JOIN items it ON it.item_id = i.itemId
JOIN items it2 ON it2.item_id = ri.item_id
WHERE MATCH(i.itemName) AGAINST(@SEARCH)
ORDER BY score DESC, id1.item_id;
如果需要更多详细信息,请询问。
丑陋的,我或多或少意味着简化,因为我正在尝试将此查询扩展为“递归”以找到整个成分链(和所需的数量,但这是另一个问题)。我宁愿在一个查询中解决它,因为通过php脚本执行它似乎也需要太长时间。只是试图优化它。
我可以省略itemNames连接,并使用另一个查询从脚本执行此操作,但我试图弄清楚如何一次性完成所有操作。我开始认为这是不可能的。
(省略了一些不相关的字段)
示例数据
项目:
item_id | hasRecipe | isIngredient
--------------------------------------
1 N Y
2 N Y
3 Y Y
4 Y N
recipe_ingredients:
recipe_id | item_id | count
------------------------------
1 2 2
1 3 1
2 1 4
recipe_detail:
recipe_id | output_item_id
--------------------------
1 4
这样做的最终目的是允许某人选择一个项目,并获得创建该项目所需内容的分层显示,这就是为什么我要尝试修剪一些项目以使用递归方式( @var方法我猜)查询一次性拉它然后解析它。到目前为止,最长的结果可能是10或12步。
答案 0 :(得分:0)
您可以随时使用视图。
CREATE VIEW view_name_goes_here AS
SELECT i.itemName item, id1.preview, it.isIngredient, it.hasRecipe, i2.itemName ingredient, id2.preview, it2.hasRecipe, ri.count AS needed, MATCH(i.itemName) AGAINST(@SEARCH) score
FROM recipe_detail rd
JOIN item_detail id1 ON id1.item_id = rd.output_item_id
JOIN recipe_ingredients ri ON ri.recipe_id = rd.recipe_id
JOIN item_detail id2 ON id2.item_id = ri.item_id
JOIN itemNames i ON i.itemId = id1.item_id
JOIN itemNames i2 ON i2.itemId = id2.item_id
JOIN items it ON it.item_id = i.itemId
JOIN items it2 ON it2.item_id = ri.item_id
然后你可以选择反对视图。