Vale a pena criar no funções no banco de dados?
Fiquei em dúvida em relação a isso!!!
Obrigado desde já!!!
Como não?!
Pesquise sobre vantagens e desvantagens de se ter a regra de negócio no banco de dados ao invés de tê-la na aplicação. Por favor, não pergunte isso a um DBA
porque senão já saberemos a resposta! rs.
Abraços,
André AS
Bom… essa pergunta é beeeeeeeem relativa…
Precisa saber qual o tipo de aplicação…
Tipo em um ERP!!!
Também se puder em um software normal… que não seja erp!!!
Bom… eu nunca trampei com um ERP e não sei o volume a velocidade de dados que vocẽ precisa em uma aplicação desse tipo…
Mas eu trampo em banco e temos um Sistema de contabilidade que necessita de um volume de informações financeiras gigantescas que inviabilizaria que todas as regras estivessem na aplicação… Logo, sempre que precisamos de algo ṕara calcular saldos por linha de um Select ou coisa do tipo, é criado uma Function para fazer isso… Fora que em nossa infra, as máquinas onde ficam os BDs são BEEEEMMMM mais potentes que as do AS… Enfim… precisas entender tua infra e decidires se vale a pena ou não ter regras no BD…
Já existem motores de regras que separam as regras, tanto da aplicação quanto do Banco de Dados… Acho que o Drools faz essa função…
Precisas entender teu Sistema e tua infra…
Abs []
eu acho que em certos casos sim… considere algumas coisas, por exemplo qual a chance de isso precisar de manutenção com freqüência? se precisar que a manutenção seja feita com freqüência não aconselho deixar no banco de dados. Outra coisa a se considerar, pensa em certo cenário, onde você faz uma busca e para cada resultado da busca você faz outro insert/update/etc… nesse caso também acho que compensa deixar no banco, por que senão isso geraria um trafego desnecessário na rede, meio grande dependendo da quantidade de dados manipulada…
não existe uma resposta padrão para essa pergunta, a resposta correta eu imagino que seja “cada caso é um caso”…
Em qualquer coisa na vida, cada caso é um caso.
Mas criar funções em bancos de dados é sim uma boa prática, além das funções propriamente ditas, mais especificadamente, também me refiro a Stored Procedures e Triggers.
Vc deve dividir a responsabilidade de validações dos dados da sua aplicação, todas as camadas da sua aplicação devem validar a entrada antes de processá-la, isso é bom porque:
:arrow: Se uma das camadas tiver um “bugzinho” na validação que você não percebeu, a camada posterior sempre tem a chance de capturar o erro antes que ele passe despercebido;
:arrow: Se seu sistema (web, por exemplo) for invadido, o banco de dados terá uma senha em separado e a probabilidade do invasor “deitar e rolar” é menor.
Além disso, vc tira da aplicação a obrigatoriedade de criar a cláusula SQL que vai fazer sua consulta ou inserção no banco, isso é bom porque se você mudar a estrutura de uma tabela, o máximo que você precisará mudar na aplicação são os parâmetros que a proc recebe, toda a lógica será mudada no SGBD.