php - 您如何管理 SQL 查询

Question

目前我的代码(PHP)中有太多的 SQL 查询。例如...

// not a real example, but you get the idea...
$results = $db->GetResults("SELECT * FROM sometable WHERE iUser=$userid");
if ($results) {
    // Do something
}

我正在考虑使用存储过程来减少这种情况并使事情变得更健壮，但我有一些担忧..

我在网站周围使用了数百个不同的查询，其中许多非常相似。当所有这些查询从它们的上下文(使用结果的代码)中删除并放置在数据库的存储过程中时，我应该如何管理它们？

Answer 1

最适合您的行动方案将取决于您如何进行数据访问。您可以采取三种方法:

使用存储过程

将查询保留在代码中(但将所有查询放入函数中并修复所有内容以使用 PDO 作为参数，如前所述)

使用 ORM 工具

如果您想将自己的原始 SQL 传递给数据库引擎，那么如果您只想从 PHP 代码中获取原始 SQL，但保持相对不变，那么存储过程将是您的最佳选择。存储过程与原始 SQL 的争论有点像一场圣战，但 K. Scott Allen 在一篇关于 versioning databases 的文章中提出了一个很好的观点——尽管是一次性的。 :

Secondly, stored procedures have fallen out of favor in my eyes. I came from the WinDNA school of indoctrination that said stored procedures should be used all the time. Today, I see stored procedures as an API layer for the database. This is good if you need an API layer at the database level, but I see lots of applications incurring the overhead of creating and maintaining an extra API layer they don't need. In those applications stored procedures are more of a burden than a benefit.

我倾向于不使用存储过程。我曾参与过一些项目，其中 DB 具有通过存储过程公开的 API，但存储过程可能会施加一些自身的限制，并且这些项目都在不同程度上使用了代码中动态生成的原始 SQL 来访问 DB。

在 DB 上有一个 API 层可以更好地划分 DB 团队和开发团队之间的职责，但代价是如果将查询保留在代码中，您将获得一些灵活性，但是 PHP 项目不太可能具有相当大的规模有足够多的团队从这种划分中受益。

从概念上讲，您可能应该对数据库进行版本控制。然而，实际上，您只对代码进行版本控制的可能性要比对数据库进行版本控制的可能性大得多。当您更改代码时，您可能会更改您的查询，但是如果您正在更改针对数据库存储的存储过程中的查询，那么您在 checkin 代码时可能不会 checkin 这些查询，并且您会丢失对应用程序的重要区域进行版本控制的许多好处。

不管你是否选择不使用存储过程，你至少应该确保每个数据库操作都存储在一个独立的函数中，而不是嵌入到你的每个页面的脚本中——本质上是你的数据库的一个 API 层使用您的代码进行维护和版本控制。如果您正在使用存储过程，这实际上意味着您的数据库有两个 API 层，一个用于代码，另一个用于数据库，如果您的项目没有单独的团队，您可能会觉得这不必要地使事情复杂化。我当然知道。

如果问题是代码整洁，有一些方法可以使包含 SQL 的代码更具表现力，下面显示的 UserManager 类是一个很好的开始方式 - 该类只包含与“用户”表相关的查询，每个查询在类中都有自己的方法，查询缩进到准备语句中，并按照您在存储过程中格式化它们的方式进行格式化。

// UserManager.php:

class UserManager
{
    function getUsers()
    {
        $pdo = new PDO(...);
        $stmt = $pdo->prepare('
            SELECT       u.userId as id,
                         u.userName,
                         g.groupId,
                         g.groupName
            FROM         user u
            INNER JOIN   group g
            ON           u.groupId = g.groupId
            ORDER BY     u.userName, g.groupName
        ');
        // iterate over result and prepare return value
    }

    function getUser($id) {
        // db code here
    }
}

// index.php:
require_once("UserManager.php");
$um = new UserManager;
$users = $um->getUsers();
foreach ($users as $user) echo $user['name'];

但是，如果您的查询非常相似，但您的查询条件中有大量排列，例如复杂的分页、排序、过滤等，则对象/关系映射器工具可能是可行的方法，尽管要对现有代码进行大修使用该工具可能非常复杂。

如果您决定研究 ORM 工具，您应该查看 Propel ，Yii的ActiveRecord组件，或国王爸爸 PHP ORM，Doctrine .每一个都使您能够使用各种复杂的逻辑以编程方式构建对数据库的查询。 Doctrine 是功能最齐全的，允许您使用 Nested Set tree pattern 之类的东西来模板化您的数据库。盒子外面。

在性能方面，存储过程是最快的，但通常比原始 sql 差不了多少。 ORM 工具可以通过多种方式对性能产生显着影响 - 低效或冗余查询、在每个请求上加载 ORM 库时的巨大文件 IO、每个查询的动态 SQL 生成......所有这些都会产生影响，但是与使用手动查询创建自己的数据库层相比，使用 ORM 工具可以用更少的代码显着增加可用的功能。

Gary Richardson不过，这是绝对正确的，如果您打算继续在代码中使用 SQL，则无论您使用的是查询还是存储过程，都应该始终使用 PDO 的准备好的语句来处理参数。输入的净化由 PDO 为您执行。

// optional
$attrs = array(PDO::ATTR_PERSISTENT => true);

// create the PDO object
$pdo = new PDO("mysql:host=localhost;dbname=test", "user", "pass", $attrs);

// also optional, but it makes PDO raise exceptions instead of 
// PHP errors which are far more useful for debugging
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$stmt = $pdo->prepare('INSERT INTO venue(venueName, regionId) VALUES(:venueName, :regionId)');
$stmt->bindValue(":venueName", "test");
$stmt->bindValue(":regionId", 1);

$stmt->execute();

$lastInsertId = $pdo->lastInsertId();
var_dump($lastInsertId);

警告:假设 ID 为 1，上面的脚本将输出 string(1) "1" . PDO->lastInsertId()无论实际列是否为整数，都以字符串形式返回 ID。这对您来说可能永远不会成为问题，因为 PHP 会自动将字符串转换为整数。

以下将输出 bool(true) :

// regular equality test
var_dump($lastInsertId == 1); 

但是如果你的代码期望值是一个整数，比如 is_int或 PHP 的 "is really, truly, 100% equal to"运算符(operator):

var_dump(is_int($lastInsertId));
var_dump($lastInsertId === 1);

你可能会遇到一些问题。

编辑:关于存储过程的一些很好的讨论 here