Estou participando de um processo de customização de um ERP onde praticamente toda regra de negócio é feita no SQL Server. Qual a opinião de vocês sobre isso? Além disso, gostaria de outra opinião. O uso de udf’s e views é util? Por que a empresa que desenvolveu o ERP adora stored procedures. Cada processo é feito dentro de uma única stored procedure monstro, umas com até 3 mil linhas. Eles alegam que usar udf’s e views apenas deixaria o processo mais lento. Agradeço aqueles que deixarem suas opiniões.
Ola !! Eu trabalho com pl/sql (oracle) em uma emprsa de medicamentos ,todas as regras de negócio são utilizadas trigger,procedures,views,functions ,package.Não vejo problemas e serem tratadas estas regras diretamente no banco ,pois são muitas transações todos os dias e é necessário otimizar ao maximo. Acho que a performance seria muito melhor se eles separacem as regras do que ter de ler 3000 linhas ou mais ,a questão das views é lógico que seria mais rápido a consulta dos dados necessários ,já que a consulta não irá percorrer toda a tabela e tambem ,retringiria os usuários não autorizados a não poderem visualizar os campos que não os competem. Acho que seria melhor repensar na reorganização destas regras ,pois certamente elas irão tomar uma dimensão maior futuramente e qualquer pessoa que prescisar efetuar a manutenção tera uma certa dificuldade. O ideal seria avaliar uma segunda opnião de outra consultoria.
Até mais…
Regra de negócios no banco de dados hoje em dia é inaceitável. A unica coisa pra mim que justifica uma stored procedure por exemplo seria um mega relatório. E mesmo assim eu tentaria entender com meu cliente o porque daquele relatório e apresentar uma solução melhor pra ele, fornecendo o mesmo resultado ou melhor.
Acho que inaceitável não seria um bom termo visto que a todo momento é lançado um framework
para mapeamento objeto-relacional e outras técnicas de para maximizar performances. Quando se tem um software relativamente pequeno concordo em
manter as regras pelo próprio software,mas quando se tem relatórios que deve trazer muitos de dados seria bom repensar nesta caso,
pois o que torna o software lento é o processo de quantas vezes ele tem que buscar estes valores no banco de dados .E já no caso anterior ele está utilizando uma metodologia que preza este tipo de organização.
ATT FLAVIO.KENSHIN
Se um relatório traz muitos dados, estes não serão avaliados pelo usuário com certeza ( exceto casos especiais ), então um relatório longo não acredito que possa ser usado como justificativa.
Salvo casos especiais de performance crítica, hoje em dia não acho viável regras em banco de dados, dificulta depuração, e fica mais difícil encontrar uma falha logica. ( fora que seu sistema fica totalmente dependente do fornecedor de banco de dados )
[quote=flavio.kenshin] Acho que inaceitável não seria um bom termo visto que a todo momento é lançado um framework
para mapeamento objeto-relacional e outras técnicas de para maximizar performances[/quote]
Não entendi o que isso tem a ver com regra de negócios no banco. Poderia explicar?
[quote=flavio.kenshin]Quando se tem um software relativamente pequeno concordo em
manter as regras pelo próprio software[/quote]
O que você chama de software relativamente pequeno!? São justamente os softwares mais complexos que se beneficiam da utilização correta de OO.
Com relação a relatórios já dei a resposta no post anterior.
Temos aqui é um choque de forças. ( Entre os dois lados da força huehue)…
Pessoal, quem programa só em Java naturalmente nunca iria defender que as regras de negócio ficassem no banco! Temos por ai toneladas de aplicações que tem suas regras de negócio em stored-procedures, exemplos são os sistemas desenvolvidos em Oracle Forms/Reports, Power Builder e por ai vai.
E os principais argumentos do povão são:
-StoreProcedures são mais rápidas.
-É mais produtivo.
-Posso mudar de linguagem e mantenha todas as minhas regras de negocio.
Convencer que essa prática não é uma boa prática é dificil. essa cultura não vai mudar da noite pro dia. Na verdade ele é tão enraizada que tenho medo que nós sejamos convecidos a adota-lá.
"
Oi,
Eu acho que uma das situações que justifica o uso é quando o seu sistema tem que acessar uma DB na qual você não é o DBA
Neste caso o mais lógico e seguro seria você pedir para quem é o dono criar uma Stored Procedure que retorna o que você precisa e apenas chamá-la no programa
Abs
Eu acho radicalismo inaceitável.
Eu acho radicalismo inaceitável.[/quote]
Se você ler o resto da minha mensagem verá o caso onde acho justificavel. Caso tenha algum outro exemplo onde seja aceitável, por favor coloque aqui no forum. Tenho certeza que agregará bem mais do que um simples “Eu acho radicalismo inaceitável”.
PS: Não dê quote pela metade pra distorcer a mensagem, ok?
[quote=“Emerson Macedo”]Se você ler o resto da minha mensagem verá o caso onde acho justificavel. Caso tenha algum outro exemplo onde seja aceitável, por favor coloque aqui no forum. Tenho certeza que agregará bem mais do que um simples “Eu acho radicalismo inaceitável”.
PS: Não dê quote pela metade pra distorcer a mensagem, ok?[/quote]
… não vi onde distorci alguma coisa. Quotei uma frase até seu ponto final… mas deixa pra lá:
Ainda acho que radicalismo é inaceitável, principalmente ao definir critérios para uma arquitetura. Pra mim afirmar que não deve se aceitar determinada tecnologia que oferece recursos que podem lhe resolver um problema levantado pelo cliente, não tem fundamento.
Não é só “mega relatórios” que se beneficiam da performance de processos rodando em banco de dados. Todo e qualquer processo que utilize de grandes consultas associadas a regras, como queries em dados desustruturados de BI (que não é simplesmente relatórios), que tem por requisito não ultrapassar a barreira de “x” tempos… ou ainda triggers de bancos legados que iniciam localmente dados para uma nova base em real-time podem se valer de recursos particulares de cada banco.
É aquela velha história da ferramenta certa para cada caso, sem pensar em arquitetura de caixinha (isso ja virou frase de parachoque de caminhão)… do tipo “dessa água não beberei”.
Se Stored Procedure satifaz certo requisito que outro método não satisfaz, utilize…
[quote=Alessandro Lazarotti][quote=“Emerson Macedo”]Se você ler o resto da minha mensagem verá o caso onde acho justificavel. Caso tenha algum outro exemplo onde seja aceitável, por favor coloque aqui no forum. Tenho certeza que agregará bem mais do que um simples “Eu acho radicalismo inaceitável”.
PS: Não dê quote pela metade pra distorcer a mensagem, ok?[/quote]
… não vi onde distorci alguma coisa. Quotei uma frase até seu ponto final… mas deixa pra lá:[/quote]
Cortou sim, mas como você bem disse, deixemos pra lá …
Ainda acho que radicalismo é inaceitável, principalmente ao definir critérios para uma arquitetura. Pra mim afirmar que não deve se aceitar determinada tecnologia que oferece recursos que podem lhe resolver um problema levantado pelo cliente, não tem fundamento. [/quote][/quote]
Já foi dito anteriormente em que casos onde a performance para busca dos dados em grande quantidade é extremamente crítica, é valido, não entendi o ponto.
[quote=Alessandro Lazarotti]
Não é só “mega relatórios” que se beneficiam da performance de processos rodando em banco de dados. Todo e qualquer processo que utilize de grandes consultas associadas a regras, como queries em dados desustruturados de BI (que não é simplesmente relatórios), que tem por requisito não ultrapassar a barreira de “x” tempos… ou ainda triggers de bancos legados que iniciam localmente dados para uma nova base em real-time podem se valer de recursos particulares de cada banco. [/quote]
Se você parasse um pouquinho para entender o que eu escrevi, perceberia que quando se fala em “mega relatório” pode-se entender por “um acesso ao banco que necessida de grande quantidade de dados de forma trabalhada”. Você está se apegando a palavra usada para distorcer mais uma vez. Volto a dizer: Sem requisitos de acesso a dados com volumes gigantes, como eu disse desde o primeiro post, o local mais indicado para se colocar as regras de negócio nos dias de hoje são nos objetos da sua aplicação.
[quote=Alessandro Lazarotti]
É aquela velha história da ferramenta certa para cada caso, sem pensar em arquitetura de caixinha (isso ja virou frase de parachoque de caminhão)… do tipo “dessa água não beberei”.
Se Stored Procedure satifaz certo requisito que outro método não satisfaz, utilize… [/quote]
Acho que você está esquecendo que isso é um forum de Arquitetura de Sistemas onde tentamos discutir as melhores práticas da atualidade. Quando o colega falou que está desenvolvendo um sistema de ERP, pelo que pude perceber, não pareceu que existia um requisito desse tipo. Pelo contrário, ele reclamou que as stored procedures eram um monstro (segundo nosso amigo: até 3 mil linhas), e isso estava ferrando com o trabalho dele. Ninguém disse “dessa água não beberei”, ninguém está propondo arquitetura de caixinha. Estamos falando de melhores práticas para os dias de hoje. Se é da sua época, já se foi o tempo onde professor de faculdade ensinada que regra de negócios se poe no banco (Se bem que ainda deve ter alguns que ensinam isso). É disso que estamos falando. Nada disso tem a ver com engessar aqruitetura.
É lamentável você perder seu tempo (e o meu) distorcendo um post para criar um flame sem necessidade.
Qual o custo de dar manutenção nessas regras?
E eu não entendi oq você não entendeu.
Emerson, não comentei sobre o post inicial, mas fiz sobre o seu comentário, isso é natural em um fórum. Eu li o que você escreveu e não achei coerente, por isso submeti minha resposta.
Isso é mesmo um fórum de discussão sobre arquitetura, logo é normal que idéias expressas (ou mal expressas) aqui possam ser debatidas. Não entendo sua revolta. Se você acha que é flame discordar de algo que você diz ou tentou dizer, paciência.
[]'s
PS: Eu não perco meu tempo em fórum. Se posto, é pq achei relevante. Pelo menos essa é minha postura.
Quanto ao tempo que vc perder, eu não posso fazer nada.
E eu não entendi oq você não entendeu.[/quote]
Não entendi o ponto pois você argumentou em cima de uma coisa que eu havia dito por não ter lido o que eu escrevi ou simplesmente ignorado.
[quote=Alessandro Lazarotti]
Emerson, não comentei sobre o post inicial, mas fiz sobre o seu comentário, isso é natural em um fórum. Eu li o que você escreveu e não achei coerente, por isso submeti minha resposta.
Isso é mesmo um fórum de discussão sobre arquitetura, logo é normal que idéias expressas (ou mal expressas) aqui possam ser debatidas. Não entendo sua revolta. Se você acha que é flame discordar de algo que você diz ou tentou dizer, paciência.
[]'s[/quote]
Meu comentário foi em relação ao POST inicial, portanto, quando responder a uma frase, leve em conta o contexto em questão e a pergunta de quem abru a thread. Você fez o mesmo que responder a uma pergunta “Comer batata frita engorda?” e alguém respondesse: “É inaceitável comer batata frita” (logico que pra quem não quer engordar) e outra pessoa viesse logo após dizendo: " Eu acho radicalismo inaceitável", sem considerar o contexto. Foi exatamente isso que você fez. E não é flame discordar, mas sim distorcer o que os outros falam pra querer aparecer.
PS: Eu não perco meu tempo em fórum. Se posto, é pq achei relevante. Pelo menos essa é minha postura.
Quanto ao tempo que vc perder, eu não posso fazer nada.[/quote]
De relevante não teve nada. Quanto ao meu tempo perdido, basta você responder o que for agregar alguma coisa ao invés de gerar uma flame só para chamar atenção. Isso é coisa de troll. Sinceramente não acredito que você seja esse tipo de pessoa.
Eu não lí, nem agora voltando, que você tenha dito onde a performance para busca dos dados em grande quantidade é extremamente crítica, é valido. Você citou um fim (relatório), mas não o meio (uma consulta). Consultas não servem apenas para fins de relatórios. Além disso, tbm coloquei que não é apenas para processos que envolvam grandes consultas mas tbm para alguns serviços de integração que estão, por exemplo em mesma base ou mesmo para atividades de BI.
Entendi perfeitamente o contexto da pergunta inicial, entendi sua colocação, contudo tenho a minha opinião. A qual já explanei.
[quote=“Emerson Macedo”]
De relevante não teve nada. Quanto ao meu tempo perdido, basta você responder o que for agregar alguma coisa ao invés de gerar uma flame só para chamar atenção. Isso é coisa de troll. Sinceramente não acredito que você seja esse tipo de pessoa.[/quote]
Como disse, posto o que eu julgo relevante, assim como acho que você faz o mesmo, ou pelo menos deveria. Se o que “você ou eu” postar agrega ou não é muito relativo, tão quanto o que achamos que seria de relavância, portanto, vamos continuar no autruísmo. A questão da insinuação quanto a “flames”, “querer chamar atenção”, “trolls” vou simplesmente ignorar, pq isso sim, de nada agrega e foge de qualquer discussão que eu esteja disposto a participar em um fórum de tecnologia.
Enfim, peço sinceras desculpas por ter “quotado” seu post inicial, desconsidere, já que isso lhe incomodou tanto.
[]s
Também sou do time que não é tão inaceitável assim implementar regras de negócio no banco. Especialmente se eu estiver desenvolvendo sistemas que nunca usufruirão dos benefícios de manter as regras em um modelo do domínio, por exemplo. Pra falar a verdade, pra certos sistemas nem Java eu usaria.
Adicionando à lista de frases de caminhão: otimização prematura é a fonte de todo o mal ( putz, já virou lugar-comum :? )
Cara tem casos e casos.
Eu acho que nao vale a pena criar procedures com coisinhas pequenas que nao vao fazer nenhuma diferenca, por exemplo, quando eu trampava no Brasil comecaram a desenvolver um site em php/mysql, ai o cara que era “arquiteto” (que por sinal nao era nem formado em computacao) achou que era uma boa ideia criar procedures pra cada consulta no banco, mesmo aquelas mais estupidas tipo “select * from users where userID = ?”, procedure de 3 linhas, resultado o banco ficou com trocentas milhoes de procedures que nao faziam a menor diferenca de estar la ou nao.
Aqui onde eu trabalho, quando eu vi que tinha umas procedures no banco eu pensei “ihhhh fodeu” mas todas sao procedures se justificam, por exemplo, esses dias eu escrevi uma procedure que obtem itens em um site por exemplo um blog que foram mais votados, usando como base uma formula doida. O que eu fiz foi criar um funcao com essa formula, e criar uma procedure que pega dados de varias tabelas aplicando essa formula, ai me retornava somente os dados que eu realmente precisava.
Acredito que se eu fizesse isso sem procedure ia tomar muito tempo porque primeiro eu teria que buscar no banco todos os registros e aplicar a formula de calculo via programacao, totalmente inutil trazer todos os registros se o que me interessa sao somente 10 baseados em calculos.
Nesse caso eu acho que a procedure eh uma mao na roda.
//Daniel
[quote=peczenyj]
Qual o custo de dar manutenção nessas regras?[/quote]
Na verdade, isso nem foi levantado como hipótese já que o sistema não é nosso. Estamos apenas adquirindo. Levantei essa questão por que eu particulamente acho estranho deixar tudo, eu disse tudo, no banco de dados. O aplicativo (feito em não sei qual linguagem, mas suspeito que Delphi) serve apenas como uma interface de operação para o usuário.