我开发了一种方法来从文件中读取复杂或冗长的查询,而不是直接在代码中读取,以避免混乱并提供对查询本身的快速引用。然后我被告知这不是首选,因为脚本必须从文件中读取,因此速度较慢。这是我的例子:
file:sql / get_code_matches.sql
/**
* returns list of new codes
* from old code entry
* @param source - string oldcode
* @param startdate - YYYY-MM-DD format only
* @return mixed multi-dimensional array on success; false on no record
* @see @DB::is_error() in code for thrown exceptions
*
*/
SELECT NULL,
g.source,
g.target,
dx9.NAME AS oldcode,
dx9.DESCRIPTION old_description,
dx10.NAME AS newname,
dx10.DESCRIPTION AS new_description,
g.flags,
SUBSTR(g.flags, 4, 1) AS scenario,
SUBSTR(g.flags, 5, 1) AS POSITION,
SUBSTR(g.flags, 1, 1) AS approximate,
SUBSTR(g.flags, 3, 1) AS combination,
SUBSTR(g.flags, 2, 1) AS matches,
CASE
WHEN SUBSTR(g.flags, 2, 1) = 1 THEN 'No Matches'
ELSE 'Matches'
END AS MATCH TYPE,
CASE
WHEN SUBSTR(g.flags, 3, 1) = 1 THEN 'Combination Matches'
ELSE CASE
WHEN SUBSTR(g.flags, 1, 1) THEN 'Approximate Matches'
ELSE 'Match'
END
END AS status
FROM tablex g
LEFT JOIN tabley dx10 ON dx10.CODE = g.target
LEFT JOIN tablez dx9 ON dx9.CODE = g.source
WHERE 1
AND g.source = ?
AND g.startdate = ?
//然后在OOP代码的某处:
$sql = $this->db->load_sql('get_code_matches'); // reads sql from file
$results = $this->db->FetchAll($sql, $bindParams); // returns results via pdo object
sql文件夹通过.htaccess保护,并获取自定义数据库层的数据。
我们发现在我们的模型区域中更有条理地标记复杂查询,例如这些。
查询仅在需要时加载到代码中。
根据IDE的不同,“sql”文件夹始终处于打开状态,以便快速参考。在某些情况下,sql文件夹可能包含代表项目每个模块的子文件夹。
这会被视为不良做法吗?
答案 0 :(得分:3)
99.99%的网站没有任何意义。
对于0.01%高负载站点,建议将这些SQL查询放入PHP文件中,让它们在opcache中缓存,因此不会在每个请求中读取。
答案 1 :(得分:1)
我认为将这些MySQL查询存储在单独的文件中是一个非常好的主意。我不确定你是如何包含这些文件的,但性能损失可能微不足道。即使这会使脚本 略微 变慢,我认为拥有更多可维护代码也是值得的。
我经常看到人们正在进行各种微观优化(只需查看is_null($a)
与$a === null
上的comments),而且它永远不值得。有很多事情要优化,实际上很重要,但这不是其中之一。