差不多两年后,我发现了这个问题。我的一些同事已经回答了几个优点或缺点,我只是想根据我的个人经验补充一点意见:
正如有人所说,我也混合了使用活动记录和纯直接 sql 用于非常复杂的查询,原因是当您需要一个接收大量操作系统参数并相应更改查询的方法时使用它非常简单。例如,我有一个方法可以接收一个名为“options”的参数数组:
if(!empty($options['login']))
{
$this->db->where('tl.login', $options['login']);
}
if(!empty($options['ip']))
{
$this->db->where('tl.ip', $options['ip']);
}
if(!empty($options['sucesso']))
{
$this->db->where('tl.sucesso', $options['sucesso']);
}
if(isset($options['usuarios_existentes']) && $options['usuarios_existentes'])
{
$this->db->join('usuario u', 'tl.login = u.login');
}
else
{
$this->db->join('usuario u', 'tl.login = u.login', 'LEFT');
}
if(!empty($options['limit']))
{
$this->db->limit($options['limit']);
}
else
{
$this->db->limit(50);
}
return $this->db->select('tl.id_tentativa_login, tl.login, DATE_FORMAT(tl.data, "%d/%m/%Y %H:%i:%s") as data, tl.ip, tl.sucesso', FALSE)
->from('logs.tentativa_login tl')
->order_by('tl.data', 'DESC')
->get()->result();
当然这只是一个简单的例子,但是我已经构建了具有数百行和条件的方法,可以更改通用的“get”方法,并且活动记录使它非常好并且非常易读,因为您不需要在中间编写代码它以正确格式化查询。
您甚至可以有连接和其他可以有条件的东西,因此您可以使用通用的集中式方法,这样可以避免重写大部分代码并复制其中的一部分(对于维护来说很糟糕),它不仅可读,而且可以保持您的查询速度很快,因为只加载您需要的内容:
if(!empty($opcoes['com_maquina']))
{
if(strtoupper($opcoes['com_maquina'])=='SIM')
{
$this->db->join('maquina m', 'm.id_local = l.id_local');
}
elseif(strtoupper($opcoes['com_maquina'])=='NAO')
{
$this->db->join('maquina m', 'm.id_local = l.id_local', 'LEFT');
$this->db->where('m.id_maquina IS NULL');
}
}
activerecord 的另一个优点是它在语句中接受纯 SQL,如子查询和其他内容,因此您可以随意使用它。
我说的是优点,但是很明显纯 SQL 总是会执行得更快,并且不会有调用函数的开销。但说实话,大多数情况下php解析器会做的很快,不会以一种表现力的方式影响最终结果,如果你必须做很多手动条件,你的代码可能和activerecord一样慢无论如何解析器。
请注意,有时 activerecord 查询不会按您期望的方式工作,因为它会尝试以编程的逻辑方式构建查询,因此例如在使用“OR”语句时要小心,大多数时候您必须隔离它(和):
$this->db->where('(m.ultimo_status < DATE_ADD(NOW(), INTERVAL -2 HOUR) OR m.ultimo_status IS NULL)');
如果不添加 ( ),OR 语句将影响整个 where 子句。所以,一旦你习惯了 activerecord,它可以提供很多帮助,并且仍然可以进行快速且可读的查询。