Regras de negócio no Select - Fazer sum é regra de negócio?

Não.
Sum é uma das várias funções que se pode executar com SQL.

Eu acho até melhor do que somar tudo no Java.

A mesma coisa quando alguma lista deve ser ordenada, como de Unidade Federativa. Eu prefiro fazer um ORDER BY na query do que dar um sort depois.

Rodrigo Sasaki:

Eu acho até melhor do que somar tudo no Java.

A mesma coisa quando alguma lista deve ser ordenada, como de Unidade Federativa. Eu prefiro fazer um ORDER BY na query do que dar um sort depois.

SELECT * FROM clientes;

E depois comparo no aplicativo. Eu simplesmente faço

SELECT * FROM clientes c WHERE c.nome LIKE '%JO_O%';

E aí eu já obtenho só os que preciso.

Bom exemplo.

Resumindo, faça seu SUM e seja feliz

É bom saber opinião de outras pessoas, espero que bastante gente responda ao tópico, é um bom tema a ser discutido.

Obrigado aos que responderam até agora

Assim, não sei se há tanto para ser discutido …

É a velha história de usar a ferramenta adequada para cada caso. Banco de dados é um recurso que deve ser aproveitado ao máximo. Assim, funções como ordenação, agrupamento, agregações, somas, etc. São melhor desempenhadas pelo banco, afinal você aproveita a compilação das queries, caches, índices, etc.

Por outro lado, se você precisa executar algoritmos sobre esses dados, é a hora de se pensar na aplicação, pois as extensões procedurais dos bancos não são padronizadas e tendem a criar gargalos nas bases.

Concordo.

Eu acho q depende se existe alguma regra para arredondamento.

O importante é atentar para como vc guarda no banco de dados, se esta trabalhando com dados financeiros.

mysql por exemplo tem problemas somando ponto flutuante.

http://dev.mysql.com/doc/refman/5.0/en/problems-with-float.html

janes:

Eu acho q depende se existe alguma regra para arredondamento.

O importante é atentar para como vc guarda no banco de dados, se esta trabalhando com dados financeiros.

mysql por exemplo tem problemas somando ponto flutuante.

http://dev.mysql.com/doc/refman/5.0/en/problems-with-float.html

Mas isso não é problema do MySQL, muito menos regra de negócio. Pontos flutuantes são imprecisos por natureza, pois são armazenados em formato binário. Assim, números que possuem precisão finita na base decimal podem possuir representação infinita na base binária. Esse “problema” do ponto flutuante vai aparecer não apenas no MySQL, mas em qualquer banco de dados ou linguagem de programação.

Nesses casos, o ideal é usar representações decimais para armazenar e manipular números, como o tipo DECIMAL do SQL ou o BigDecimal do Java. Nesse caso, a precisão ainda é limitada, mas já é bem melhor do que a pontos-flutuantes. Em compensação, essa representação é muito mais cara em termos de memória e processamento.

De qualquer maneira, é mais uma questão de arquitetura e implementação do que regra de negócio em si.

ismael.costa:

Tenho um select que me traz um objeto, porém nesse select eu retorno a soma de três colunas, não há nenhuma regra para a soma, simplesmente são somadas
as colunas, isso é uma má prática? Fazer sum num Select? Ou o ideal é trazer todas as linhas e somar no próprio Java? Tenho essa dúvida pois na minha opinião fazer
sum não é regra de negócio, a menos é claro que haja uma regra de como efetuar essa soma, aí sim concordo que tenho que trazer todas as linhas e somar dentro do Java
de acordo com a regra.

Fazer a soma no SQL é uma regra de negocio ? sim. Fazer a soma (não importa onde) é uma regra de negocio. O fato de ser uma simples soma e não haver where não significa que não é uma regra. Significa que a regra é simples ( muito provavelmente porque o modelo do banco foi feito para que fosse simples).
Deve ser feito no java ? Não. Deve ser feito onde for mais rápido. Se o banco faz mais depressa, ótimo. Mas, por exemplo, se vc tiver bilhões de linhas e precisar fazer um map/reduce, ai o mais rápido é não usar o banco.

Como regra vc deve sempre abstrair onde as coisas são feitas (se no java ou no banco) mas não o quê. O “quê” é fixo e isso é que é a regra de negocio.
Se o “quê” significa que temos que fazer um select , então o select é o “como”. O “quê” pode mudar e ainda ser um SQL ( um outro sql, mas um sql mesmo assim). E o “como” pode mudar também, e de SQL virar outra coisa (batsh, fork/join, map/reduce, web-service, sei lá … )

O “quê” só muda se o negocio muda. O “como” muda mesmo se o negocio não muda. Por simples razões da evolução da tecnologia existiram na linha do tempo vários “como” para o mesmo “quê”.