MySQL :：何时应该将SQL函数(条件、格式化)移到中间件层？

Question

多年来，我已经养成了一个习惯(不完全确定是好是坏，这是这个问题的部分原因)：使用if条件进行格式化，或使用group函数进行日期格式化，使用date函数进行日期格式化。

示例：

// Grouping: get total goals & assists for each player (1 = goal, 2,3 = assist)
SUM(IF(scoreType=1,1,0)) AS goals, SUM(IF(scoreType=2,1,IF(scoreType=3,1,0))) AS assists

// Date formatting:
DATE_FORMAT(gameDate, '%b %e') AS displayDate

// Text formatting:
IF(gameType='S','(S)','') AS gameTypeDisplay

我可以继续这样做，但我将转向基于ORM的系统，其中"select *“是默认设置，而字段替换(为了实现上述目的)虽然可能，但当您在查询中有多个条件要处理时(基本上最好是纯的、可读的SQL或ORM DSL，但不是两者的混搭，imo)就会把事情搞得一团糟。

那么，将上面的文本格式化条件转移到中间件层所涉及的成本是多少呢？例如，1,000行查询结果；循环，并对每行应用条件？

基本上，我希望清理中间件/ORM层代码并卸载方便的SQL函数，但前提是我不打算将服务器拖到缓慢的位置，因为中间件层要执行大量的额外处理。

服务器设置是最新的32位JVM ( CentOS中间件)和MySQL 5。

Answer 1

不知道你的数据结构，但我猜是：

// Grouping: get total goals & assists for each player (1 = goal, 2,3 = assist)
SUM(IF(scoreType=1,1,0)) AS goals, SUM(IF(scoreType=2,1,IF(scoreType=3,1,0))) AS assists

这些东西无论如何都不能在应用程序级别高效地完成，所以您需要将其保留在SQL中。

// Date formatting:
DATE_FORMAT(gameDate, '%b %e') AS displayDate

// Text formatting:
IF(gameType='S','(S)','') AS gameTypeDisplay

这两个都可以在应用程序中高效地完成。实际上，应该使用，因为这样做将减少数据库的工作量。

Answer 2

你可以使用一个视图。

create or replace view fancy_table AS 
   SELECT DATE_FORMAT(gameDate, '%b %e') AS gameDate,
        IF(gameType='S','(S)','') AS gameType, other, cols, here FROM table;

然后你的orm就可以在视图上使用*。

select * from fancy_table;