如何把这个大查询变成一个存储过程

Posted 2023-04-19

【中文标题】如何把这个大查询变成一个存储过程

【英文标题】：How to turn this big query into a stored procedure

【发布时间】：2014-02-19 11:19:04

【问题描述】：

我怎样才能把这个大查询变成一个存储过程我应该这样做吗？有什么好处？

SELECT * 
FROM user_items
LEFT JOIN items ON (items.item_id = user_items.item_id) 
INNER JOIN item_categories ON (item_categories.item_id = items.item_id)
INNER JOIN item_subcategories ON (item_subcategories.item_id = items.item_id)
INNER JOIN brands ON (brands.brand_id = items.item_brand)
INNER JOIN item_photos ON (item_photos.item_id = items.item_id)

INNER JOIN place_items ON (place_items.item_id = items.item_id)
INNER JOIN places ON (places.place_id = place_items.place_id)

WHERE user_items.user_id = :user_id

来自brands 表我只需要brand_name 来自places 表我只需要place_name

我现在的做法是，我从brands 和places 获取所有列，所以我的一个朋友告诉我，我可能应该考虑使用存储过程

【问题讨论】：

你想要其他表的哪些列？

项目中的所有列以及类别/子类别中的所有列

【参考方案1】：

如果您只想要品牌和商品表中的列，您可以执行以下操作

"SELECT   brands.brand_name,places.place_name,
          user_items.*,items.*,item_categories .*,
          item_subcategories.*,item_photos.*,place_items.*
 FROM user_items
          LEFT JOIN items ON (items.item_id = user_items.item_id) 
          INNER JOIN item_categories ON (item_categories.item_id = items.item_id)
          INNER JOIN item_subcategories ON (item_subcategories.item_id = items.item_id)
          INNER JOIN brands ON (brands.brand_id = items.item_brand)
          INNER JOIN item_photos ON (item_photos.item_id = items.item_id)

          INNER JOIN place_items ON (place_items.item_id = items.item_id)
          INNER JOIN places ON (places.place_id = place_items.place_id)

          WHERE user_items.user_id = :user_id"

存储过程的用途是重用一组SQL语句。存储过程的性能将与其包含的 SQL 语句一样好。

提高代码可读性的更好方法是使用 ALIASES 作为表名。

When to use SQL Table Alias

【讨论】：

这会从项目、类别、子类别中返回 * 吗？

感谢您的编辑。如果我需要更多表中越来越多的东西怎么办，是继续这样下去还是应该使用存储过程（这似乎是一个可怕的概念）

从你做的表中获取所有列tableName.*

你不应该害怕存储过程:) ...它只是一个或多个 SQL 语句集合的名称。

lolz.. 不像那个哥们...别名让你的代码更容易阅读，你的程序员同事会为你唱歌

【参考方案2】：

根据我的经验，存储过程带来的麻烦多于其价值，它不灵活，因此比内联 SQL 更难维护，位于版本控制之外，并且无法提供很多性能优势（如果有的话）。在这种情况下，存储例程似乎没有必要或有益，因为您的查询不需要高级功能，例如游标。有关优点和缺点的其他讨论，请参阅this post。

【讨论】：

我不同意 - 主要是因为绝对没有理由为什么存储过程应该在版本控制之外 - 如果是，那只是你自己的懒惰......

@marc_s 你是说 mysql 存储过程的版本控制比应用程序代码的版本控制更容易还是更难？--我发现它更具挑战性，尤其是在资源有限的情况下。另外，如何解决我的全部答案，即其他点？最后，关于“懒惰”这个话题，你的语法和标点很糟糕。

正如我所说的——我不同意——基本上你所说的一切。我不认为存储过程（以及数据库中的任何内容）的版本控制比源代码更难，我不同意您所做的不灵活且更难以维护 声明。对不起我的语法 - 英语不是我的第一语言

【参考方案3】：

    DELIMITER $$
    DROP PROCEDURE IF EXISTS `ABC` $$
    CREATE PROCEDURE `ABC`(IN UID LONG)
    READS SQL DATA
    BEGIN
    SELECT * 
    FROM user_items
    LEFT JOIN items ON (items.item_id = user_items.item_id) 
    INNER JOIN item_categories ON (item_categories.item_id = items.item_id)
    INNER JOIN item_subcategories ON (item_subcategories.item_id = items.item_id)
    INNER JOIN brands ON (brands.brand_id = items.item_brand)
    INNER JOIN item_photos ON (item_photos.item_id = items.item_id)
    INNER JOIN place_items ON (place_items.item_id = items.item_id)
    INNER JOIN places ON (places.place_id = place_items.place_id)
    WHERE user_items.user_id = UID
    END $$
    DELIMITER ;



you can do like this and execute this and can call then :-

CALL ABC(1234);

where 1234 is user_id of user. Thank you

【讨论】：

所以我用这个而不是 SQL，并且不做其他更改？