来自http://php.net/manual/en/mysqli.quickstart.prepared-statements.php的正确MySQLi参数化查询语法:
$stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)"); $stmt->bind_param("i", $id);
但永远不要这样:
$stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (:id_value)"); $stmt->bind_param("i", "id_value", $id);
在我看来,命名参数
替换是在API级别实现的合理功能。令我惊讶的是,MySQLi 在库中只实现了 未命名参数
。
有正当理由吗?看到 PDO、DQL、ORM 都如何在查询中采用命名参数,这对我来说没有意义。
我希望 MySQLi 开发人员不会出现“我们很懒且不想”的情况。我相信一定有一个很好的理由,并且我正在寻找那个理由,或者寻找那个理由的方法。 MySQLi 扩展库中未实现命名参数的原因。
传统上,MySQLi 是 MySQL API。它本身不会添加任何内容,并且是有原因的:添加命名占位符等功能将需要(如果您想到的话)整个 SQL 查询解析的庞然大物。当然,这不是数据库 API 的工作。就像其他答案中所说的那样,API 不是 DAL 或 DBAL;它们有不同的用途。
PDO 是一项您在语言中很难再看到的伟大壮举,而韦斯·弗隆 (Wes Furlong) 是一位天才,他几乎单枪匹马地承担了这项任务。但 PDO 又是另一回事了。它是一个数据库访问抽象层,为了实现这个目标,无论你喜欢与否,你都需要一个查询解析器。由于您已经有了一个查询解析器,并且其中一个驱动程序已经支持命名占位符,因此很自然地将其添加到所有支持的驱动程序中。正如您所看到的,使用 MySQLi 一切都不同了。
简单来说,不是“懒”,而是“懒”。这是关于遵循规范。
MYSQLi
不支持命名参数有两个主要原因:PDO
确实如此 - 而且没有必要重新发明轮子详细说明第 1 点:
mysqli
,尽管与PDO
相比有许多缺点,但很容易与一个好的包装器相媲美 - 即命名参数(除其他外) )由包装器而不是 mysqli 本身支持。这是设计使然,只有一个原因:Mysqli
被设计为一个快速且灵活的库。如果开发人员将更多功能合并到基础库中,与直觉相反,它就会变得不太灵活,并且需要更长的加载/执行时间。
mysqli
和pdo
都是随 PHP 5 发布的(我相信 PDO 版本为 5.3),因此有不同的用途。您想要更快的执行时间吗?使用没有包装器的
mysqli
。您想要命名参数吗?使用PDO
或构建mysqli
包装器来处理此类问题 - 但请注意,这会阻碍您的执行时间。