什么时候最好将工作卸载到RDBMS而不是用代码完成？

12

好的，我会解决的：我是一个比数据库更好的编码器，而且我想知道关于“最佳实践”的想法是关于在SQL查询中还是在SQL查询中进行“简单”计算的。代码，例如此MySQL示例（我没有编写它，我只需要维护它！）-这将返回用户名，以及用户从上次事件开始的年龄。

SELECT u.username as user, 
       IF ((DAY(max(e.date)) - DAY(u.DOB)) &lt; 0 ,   
       TRUNCATE(((((YEAR(max(e.date))*12)+MONTH(max(e.date)))
       -((YEAR(u.DOB)*12)+MONTH(u.DOB)))-1)/12, 0),  
       TRUNCATE((((YEAR(max(e.date))*12)+MONTH(max(e.date))) -            
       ((YEAR(u.DOB)*12)+MONTH(u.DOB)))/12, 0)) AS age   
FROM users as u
JOIN events as e ON u.id = e.uid
...

与在代码中进行“繁重”的提升相比：

查询：

SELECT u.username, u.DOB as dob, e.event_date as edate
FROM users as u
JOIN events as e ON u.id = e.uid

码：

function ageAsOfDate($birth, $aod)
{    //expects dates in mysql Y-m-d format...
     list($by,$bm,$bd) = explode('-',$birth);
     list($ay,$am,$ad) = explode('-',$aod);

     //Insert Calculations here 
     ...
     return $Dy; //Difference in years
}

echo "Hey! ". $row['user'] ." was ". ageAsOfDate($row['dob'], $row['edate']) . " when we last saw him.";

我敢肯定，在像这样的简单情况下，不会有太大的区别（除了我必须像第一个那样对查询进行更改时的恐怖感），但我认为这使我更清楚了我在寻找。

谢谢！

php mysql

— 双子座
source

1

这是一个好问题-我也遇到过同样的问题。

— Michael K

这是一个什么时候不做的好例子：calendar.sql（是的，那是我的怪诞，是的，这是个坏主意，不，它并不慢。）

— greyfade 2010年

是的，真是令人难以置信……我敢打赌，MD5就是“ CthulhuFhtagn”

— GeminiDomino

13

由于性能原因，您希望在数据库中执行所有基于集合的操作。因此，聚合函数，排序函数，联接等

这个年龄的计算，我会在代码中做。我可能在数据库查询中执行类似操作的唯一原因是，如果它需要很多列，而我本来不会选择这些列，那么实际上这些列实际上就足以构成足以使我的查询变慢的数据。选择一些整数值不会产生有意义的性能差异。即使性能产生适度的差异，我也会倾向于将这种逻辑保留在应用程序代码中。

— 杰里米
source

我同意。出于显示目的而摆弄值的代码应该在您的应用代码中。

— TehShrike'1

4

每种情况都不同

逻辑上...

其他客户需要的吗？DRY：在数据库中
用于进一步处理？例如，按年龄降序排序：在数据库中
需要区域设置？dd / mm / yyyy或mm / dd / yyyy：在客户端
经常使用？为什么要一遍又一遍地计算：在数据库中使用计算和持久化的列

在这种情况下，我可能会在数据库中使用一个计算和持久化的列

可能更糟：您可能在数据库中有此文件：

"Hey! ". u.username." was ". <datecalc>. " when we last saw him."

— gbn
source

3

基本上，您应该看两件事：CPU使用率和网络流量。您不应该生成巨大的响应，通过网络传输它们，然后在前端进行汇总，因为数据库可以做得更好。

对于数据操作，这是一个折衷。如果数据库在做相同的事情上花费与您的前端代码相当的cpu周期-假设传输的数据量大致相等），那么在哪里都没有关系。然后在您拥有最多编程专业知识的地方进行操作。通常，经过精心选择，您可以获得非常长的路要走，这可能非常有用。

1

您提到了一个：专业领域。也许数据库的结构不是太密集，所以您决定将一些逻辑开发工作转移给以数据库为中心的团队成员。可能不理想，但是如果您时间紧迫...

数据库硬件比其他服务器具有更多的资源，您无法更改。这可能不适用于此特定情况，但可能需要考虑。

还有其他一些应用程序可能需要代码外部的逻辑。某些报告编写工具可能无法使用Web服务或API。您可以复制逻辑，或者如果您认为需求可能有所不同。

— 杰夫
source

“数据库硬件比其他服务器拥有更多的资源，您无法更改。” -是吗？这两个陈述从何而来？

— 彼得·布顿

我认为Jeff可能正在谈论独立的数据库服务器。我可能应该指定我主要在LA [MP] P设置上工作。

— GeminiDomino

1

LAMP安装程序没有理由没有独立的数据库服务器，独立的数据库服务器也不是保证有更多资源或无法更改此资源的保证。

— 彼得·布顿

嗯不确定。

— GeminiDomino

@Peter Boughton，同一服务器中的数据库和应用程序的接口连接时间减少了几个数量级，并且整个IO都增加了数量级，确实有理由将这两个放置在一起。

— JE队列

0

我总是错误地在数据库上进行尽可能多的处理。您上面的语法也可以使用DB函数编写，这将是IMO一个非常干净的解决方案。

— JéQueue
source