Fórum [OT] Regras de negócio no banco de dados #363415

a única coisa que vejo contra o uso de stored procedures é a portabilidade do sistema entre bancos de dados.
se o sistema for vendido para um cliente que tem servidor linux, e já possui postgree ou firebird, fica complicado.
pode também acontecer de um cliente já ter um sistema utilizando Oracle e quer manter o uso do Oracle (pelo qual pagou caro).
nesses casos você terá problema.

mas se o sistema está engessado no sql server, não vejo qualquer problema no uso de stored procedures ou views para armazenar as regras de negócio do sistema (não vi a necessidade de udfs no sql server, pois ele já possui inúmeras funções).
ah... não precisa ser tudo numa única stored procedure.

Emerson, obrigado pela participação.

Confesso que utilizar stored procedures para validar as regras de negócios me incomoda. Acho que Banco de Dados não foram feitos para isso. Qual o nível de otimização das centenas de IF e Loops que as stored procedures fornecem? Será que o uso excessivo de chamadas não sobrecarrega o BD? Tudo bem que o nível de customização não tem limites. Se toda a regra está no BD você pode ter uma versão do seu software para cada cliente, mas você joga no lixo qualquer metodologia de qualidade de software.

Pessoal, outras opiniões são bem vindas.

Bom dia, RJun

Uso Banco Firebird
Apesar de nao ter ido muito adiante em uso de regras no banco (Usando SP´s, por exemplo), parei pela dificuldade de manutencao.
Sou adpto do desenvolvimento N-Tier/BSS(Com Servidor Aplicacao).
Em muitos casos, alterar algo com SP, demanda em atualizar todos os Clientes, dai o bicho pega. Fato que ja nao ocorre com o N-Tier.
Questoes de parametrização tambem e tudo mais.
A dependencia do banco fica bem menor tambem, 100¬ dependendo do teu desenvolvimento.
Pode ser tbm birra pessoal, em nao usar regras no banco, mas fico mais sussegado tbm, por nao precisar instalar Gerenciados nas maquinas clientes em alguns dos projetos, em outros se necessário, faço uso da versao ´embarcada´ para recuperar alguma coisa localmente.
...e por ai vai, tem a parte de manutencao tambem que penso ser bem mais simples.

Espero que tenha ajudado. T+

Os sistemas gerenciadores de bancos de dados relacionais (SGBDR) foram feitos para isso, sim. Eles estão preparados para essas tarefas, justamente para minimizar o procesamento externo. Fazem todo o processamento sem a necessidade de ´trafegar´ informações, o que torna o processo muito rápido.

Eu não utilizo SPs por trabalhar com programação n-tier, num sistema que pode ser implantado com Firebird, SQL Server, Oracle ou PostgreeSQL.
E essa pluralidade é possível justamente por não usar determinados recursos do banco de dados. Senão eu teria que ter várias versões das SPs, uma para cada banco de dados. A manutenção sairia muito ´cara´.

Tenho um amigo desenvolvedor que trabalha somente com Firebird. Ele usa extensivamente os recursos do banco de dados. Posso te dizer uma coisa: o sistema é um canhão! As triggers fazem a validação, as stored procedures efetuam os processos do sistema (baixa de estoque, geração de nota fiscal, geração de dados contábeis, etc) e as views geram os relatórios. O sistema é muito rápido, estável e totalmente preciso.
Mas ele terá um inconveniente se algum dos seus clientes quiser o sistema num outro SGBD: ele terá de reescrever tudo.... e isso demandará tempo e dinheiro.

Há vantagens e desvantagens. E cada caso depende de estudo.

Complementando o que o amigo emerson.en disse:

Se você usar SQL Server, Oracle ou DB2 (bancos pagos) e não por as regras dentro deles isso quer dizer que você estará usando os bancos somente como um repositório de dados. Desta forma você não estará usando o máximo de produtividade que o banco pode te oferecer.

Na empresa que trabalho temos banco SQL 2005 com 520 tabelas e 2300 storeds procedures (e 230 views, umas 80 triggers e umas 50 functions).

Se no meu sistema eu não utilizasse Stored ou outras coisas eu teria muitíssimo mais código na aplicação (VB6). A manutenção direta no banco é extremamente mais prática, sem comparação. Não necessita de recompilação e tem muita vantagem no caso de sistema Matriz x Filiais.

Por exemplo (trabalho em empresa de comércio de ferramentas) quando o usuário vai faturar um pedido. Nesse momento são processados:

- MOVIMENTAÇÃO DE ESTOQUE
- ALOCAÇÃO DO ESTOQUE
- ALOCAÇÃO DE ORDENS DE COMPRA
- CÁLCULOS DE IMPOSTOS DA NF DE SAÍDA
- GERAÇÃO DE TÍTULOS NO FINANCEIRO
- GERAÇÃO DE REGISTROS NO LIVRO FISCAL


Isso tudo numa única stored procedure onde como parametro apenas eu passo o numero do pedido. Imagina se isso fosse na aplicação. Teria que chamar dezenas de storeds (ou sql´s) para executar as operações.

E quando se tem um sistema onde o banco é remoto o ideal é ir no banco de dados o menor número de vezes. No caso de stored vc vai uma única vez e aguarda o resultado. Se houver erro vc ajusta a stored e pronto!

Na empresa tem casos assim: O CLIENTE X TEM BENEFICIO FISCAL E TERÁ ALIQUOTA DE 18¬ E NÃO 19¬ PARA PRODUTOS COM SUBSTITUIÇÃO TRIBUTÁRIA.

Quando acontece um caso assim agente prepara um parametro para tornar isso configurável e só ajusta a rotina de faturamento. Nâo recompilamos nada, apenas ajustamos o cadastro de clientes para esta nova configuração.

E além disso: STORED PROCEDURE e VIEWS são pré-compiladas dentro do banco. Sendo assim a execução delas é muito mais rápida do que usar SQL na mão.

O que tem de problema é a troca de banco, que foi mencionada. Acho que depende do sistema, da empresa, do mercado. Eu, em meu horário livre, desenvolvo um pequeno ERP e este vou deixar ´multibanco´ para poder testar. Mas quando se tem um grande sistema geralmente temos que usar o máximo que o banco pode oferecer, senão não valerá a pena pagar caro pelo banco.


Valeu.