[firebase-br] RES: RES: RES: Regras de negócio no Firebird

[Gladiston Santana]

As vezes acho que estamos falando de coisas diferentes.

Ao me referir a regras de negocio eu tomo como ponto principal a atividade
de procedimentos que agregue um resultado como o calculo de uma melhor
compra no sistema de cotações ou preço de um produto ou serviço para aquele
cliente considerando impostos, tributos, frete e todas as pataquadas que
este governo criou, consultar webservices e depois enviar email para A, B
ou C.
Também as manipulações de insert/update/delete em tabelas.
Tudo isso pode ser feito numa camada de sistema como feito em Delphi ou as
vezes numa procedure direta no banco com bem menos possibilidades de
programação.

Regras do banco é outra coisa, validações de campo e a não existencia de
registros orfãos é a base para um banco de dados sanitizado e não há como
fazer isso sem ser no banco.
Alias, o banco é o local mais indicado para isso.
Imagina eu varrer uma tabela e ver status='A' ou 'B, ou 'C' e ter que olhar
no sistema para saber o que eles significam.
Não seria melhor criar na mesma tabela campos calculados traduzindo esses
mineumonicos?

Essas regras de banco é bom ter independente de usar a solução X, Y ou Z.

Então precisamos estabelecer um meio comum aqui, porque senão haverá
diferentes interpretações.

[]´s



Em 17 de fevereiro de 2017 13:28, Rubem Nascimento da Rocha <
djpardalrocha em hotmail.com> escreveu:

> Eu também concordo que regras de negócio devem ficar em servidores de
> aplicação. No entanto, vá tentar mudar isso em organizações que possuem
> essa mentalidade de engessar banco de dados com integridades referenciais
> reforçadas em triggers, validações de campos em constraints e regras de
> negócio implementadas em stored procedures.
>
>
> Dependendo da cultura organizacional, é difícil mudar esse paradigma,
> principalmente em empresas de porte multinacional onde o desenvolvimento é
> muito restrito e/ou liderado por um time restrito que coordenada todo um
> ecosistema de aplicações usadas por toda a corporação.
>
> Se você é um desenvolvedor de software e tem a preocupação que seu produto
> rode em diferentes plataformas de banco de dados, sem dúvida o uso de
> servidores de aplicação é crucial para organização de regras de negócio,
> distribuídos em serviços, workflows, mensagerias, etc.
>
> Agora, se a cultura da empresa já é engessada, concentrando regras de
> negócio no banco de dados, dance conforme a música.
>
> Sds.
>