MySQL :: SQL函数条件，格式何时应移至中间件层？

问题描述

| 多年来，我已经习惯了使用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,IF(scoreType=3,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更好，但不能同时兼顾这两者）。 那么，将上面说的文本格式作为条件转移到中间件层所涉及的成本是多少？例如1,000行查询结果；循环，并为每行应用条件？ 基本上，我想清理中间件/ ORM层代码并卸载便利的SQL函数，但前提是我不想因为中间件层执行大量额外处理而将服务器拖到很慢的程度。 服务器设置是32位的CentOS 5，最新的JVM（Groovy中间件）和MySQL 5。     

解决方法

Dunno您的数据结构，但我的猜测是：

// 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,IF(scoreType=3,0))) AS assists

无论如何，这些东西都无法在应用程序级别上高效完成，因此您需要将其保留在SQL中。

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

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

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

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

那么您的orm可以在视图上使用*。

select * from fancy_table;