MySQL::什么时候应该将 SQL 函数(条件、格式化)移至中间件层？

Question

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

示例:

// 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，但不要将两者混合在一起)。

那么，将上面的文本格式条件转移到中间件层会涉及哪些成本？例如1000行查询结果；循环，并对每一行应用条件？

基本上，我想清理中间件/ORM 层代码并卸载便利的 SQL 函数，但前提是我不会因为中间件层执行大量额外处理而拖累服务器。

服务器设置为 32 位 CentOS 5、JVM(Groovy 中间件)和最新的 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

这两项都可以在应用程序中高效完成。事实上， should ，因为这样做意味着数据库的工作量会减少。