Devemos abandonar procedimentos armazenados e executar chamadas de banco de dados de programas Java

Question

Estou lutando para manter o uso de procedimentos armazenados em nossa empresa.Existem algumas pessoas que dizem que eles são ruins e que não devemos usá-los.Estamos usando o DB2 na série i.

Por favor, ajude no meu argumento para manter os procedimentos armazenados vivos na minha empresa.

Answer 1

Ok, vou sair a favor dos procs armazenados.

Primeiro, se você usá -los exclusivamente, eles simploram a refatoração do banco de dados, pois você pode usar as dependências armazenadas no banco de dados para descobrir o que seria afetado por uma alteração (bem no SQL Server, não pode falar para outras bases de dados).

Segundo, se você precisar alterar apenas a consulta, eles são muito mais simples de implantar.

Eles também são mais fáceis de ajustar o desempenho, pois podem ser chamados facilmente sem disparar o aplicativo.

Se você possui lógica complexa, economiza algum desempenho por não ter que enviar tudo isso pela rede para o servidor de banco de dados. Pode não parecer um grande ganho, mas se a consulta complexa for executada milhares de vezes por dia, ela poderá aumentar.

A segurança também é extremamente importante. Se você não usar procedimentos de armazenamento, deve definir direitos na tabela ou no nível de visualização. Isso abre o banco de dados para interno fraude. Sim, consultas parametrizadas reduzem o risco de injeção de SQL, mas essa não é a única ameaça contra a qual você precisa se proteger. Se você possui dados pessoais ou financeiros e não usa Procs armazenados (e outros sem SQL dinâmico) e limitam seus usuários a poder fazer apenas as coisas através do PROCS, então seu sistema está em extremo perigo de funcionários internos que podem roubar dados ou ignoram os controles internos para roubar dinheiro. Leia sobre controles internos nos padrões contábeis para ver por que isso é um problema.

O ORMS também tende a escrever apenas um código SQL ruim, especialmente se a consulta for complexa. Além disso, quando as pessoas começam a usá -las em vez de procs armazenados, descobri que as pessoas que nunca usaram o Procs armazenadas têm um entendimento mais pior de como obter dados do banco de dados e frequentemente obtêm os dados errados. O uso de um ORM é bom se você já entende o SQL e pode determinar quando reescrever o código autogenerado em algo que funciona melhor. Mas muitos usuários não têm a habilidade de escrever código complexo porque nunca aprenderam o básico.

Finalmente, como você já armazenou o Procs para sua aplicação, se livrar deles é uma maneira de introduzir novos bugs, porque você teve que gerar um novo código.

Answer 2

Você não vai gostar disso, e provavelmente vou cair no esquecimento, mas estou com o resto da sua empresa.

Os procedimentos armazenados costumavam oferecer muitos benefícios (segurança, desempenho, etc.), mas com consultas parametrizadas e melhor otimização de consultas, os procedimentos armazenados apenas adicionam outra camada de sobrecarga ao seu aplicativo e fornecem outro local necessário para atualizar/modificar o código.

Prefiro manter tudo em um único local para que, quando precisar editar o código, possa ir até um local e fazer minhas alterações lá.

Se você quiser mais detalhes sobre os argumentos para abandonar as Stored Prcoedures, confira este artigo do CodingHorror:

Codificação de terror:Quem precisa de procedimentos armazenados?

...e acabei de notar que o artigo é de 2004.Tenho que acreditar que os bancos de dados melhoraram desde então, o que significa que isso soaria ainda mais verdadeiro hoje do que naquela época.

Answer 3

Fazer tudo sobre o JDBC significa essencialmente que você está inserindo uma camada de rede entre você e o banco de dados. No geral, significa que os dados são mais "remotos" e chegam a você mais lentamente. Os procedimentos armazenados podem funcionar diretamente nos dados dentro do banco de dados, e a diferença resultante na velocidade pode surpreendê -lo.

Observe que você pode escrever procedimentos armazenados em qualquer idioma IBM I, incluindo Java, caso seja uma questão de habilidades de programação. Além disso, você tem acesso à máquina completa, não apenas a alguns bancos de dados. Aqui o AS/400 é tão diferente de qualquer outro produto de banco de dados, que experimenta outros bancos de dados simplesmente - em minha opinião - não se aplica.

Eu recomendaria as listas de discussão de médio porte, pois elas têm a maior concentração de habilidades de programação AS/400 que conheço.

Answer 4

Este é um daqueles problemas do Marmite.se você é principalmente um programador de banco de dados, pensará que os procedimentos armazenados devem ser usados ​​extensivamente.Se você é um programador de aplicativos - digamos, um codificador Java ou .Net - é provável que você diga que eles devem ser evitados completamente.

Não que isso atenda aos programadores de aplicativos que desejam escrever suas próprias instruções SQL.Não, hoje em dia eles tendem a querer abstrair tudo por trás de serviços ORM complicados.Eles não são mais fáceis de entender do que os procedimentos armazenados, mas estão disponíveis no mesmo IDE e, portanto, exigem menos alternância de contexto.

Existem duas grandes coisas a favor dos procedimentos armazenados.A primeira é que as pessoas que conhecem PL/SQL provavelmente estarão familiarizadas com bancos de dados Oracle (T-SQL e SQL Server, etc.) e, portanto, tenderão a escrever programas melhores para esse banco de dados (definidos como programas que aproveitam as vantagens da plataforma). recursos e estão adaptados à sua funcionalidade) do que pessoas que não o fazem.

A segunda coisa é que os dados persistem.Os desenvolvedores de aplicativos gostam de falar sobre “independência de banco de dados”, mas o que realmente importa é independência de aplicação.Os front-ends vêm e vão, mas o modelo de dados dura para sempre.Nos últimos dez anos, aplicações Java foram escritas como Applets, Servlets, JSPs, Tiles e Faces, com complementos em JavaScript, Groovy, AJAX e JSON, conectando-se ao banco de dados através de JDBC enrolados manualmente, EJB (v1,2, 3), TopLink, Hibernate e IBatis...perdoe-me se perdi alguns.Os aplicativos cuja UI é uma camada sobre uma camada de procedimentos armazenados são mais fáceis de atualizar para os melhores e mais recentes do que os aplicativos em que a lógica de negócios precisa ser reescrita todas as vezes.E eles também terão um desempenho melhor.

No entanto, no longo prazo, os aplicativos que interagem diretamente com o banco de dados provavelmente desaparecerão.Tudo vai falar com o barramento de serviço, que vai decidir de onde pegar os dados.É claro que lojas onde o banco de dados é exposto por meio de uma API bem projetada de procedimentos armazenados podem achar mais fácil migrar para esse admirável mundo novo do que aqueles lugares que terão que extrair tudo de sua lógica ORM.

Answer 5

Eles são úteis quando você tem um conjunto de aplicativos em camadas. Por exemplo, um banco de dados principal único com serviços da Web que oferece operações atômicas (que por acaso são procedimentos armazenados) e um ESB ou um conjunto de aplicativos que consomem esses WSs. Em um caso de aplicativo único/DB único, a idéia é manter o código em um só lugar, como os outros sugeriram.

Mas bem, sou só eu.

Answer 6

Sou um desenvolvedor de Java de longa data que recentemente se deparou com vários projetos que fizeram uso pesado de procedimentos armazenados que colocaram o uso de procedimentos armazenados em uma luz muito ruim para mim.

Dito isto, estou relutante em fazer uma declaração geral de que os procedimentos armazenados são ruins como uma opção de design do sistema, porque realmente depende do projeto em questão e do que os procedimentos armazenados específicos estão tentando realizar.

Minha preferência é evitar qualquer tipo de procedimento armazenado para operações simples de CRUD (pode parecer risível para que alguns procedimentos armazenados lidam com essas operações, mas encontrei vários sistemas que estavam fazendo isso) - isso acaba resultando em muito de código que deve ser escrito (e testado e mantido) no lado Java para gerenciar essas chamadas de procedimento do que observei. É melhor usar apenas o Hibernate (ou alguma outra biblioteca ORM) para lidar com esses tipos de operações ... se não houver outro motivo senão reduzir a quantidade de código que precisa ser mantida. Também pode causar problemas ao tentar refatorar ou fazer alterações significativas no sistema, pois você não precisa apenas se preocupar com as alterações de classe/tabela, mas também armazenaram procedimentos que lidam com o CRUD OPS. E isso pode ser exacerbado ainda mais se você estiver em uma situação em que os desenvolvedores não possam fazer alterações no banco de dados, ou existe algum processo formal para coordenar as alterações entre as duas partes do sistema.

Por outro lado, tendo procedimentos armazenados que requerem interação limitada com o código Java (basicamente, você apenas dispara uma chamada para um com alguns argumentos) e o funcionamento de uma maneira semi-autônoma também não é uma coisa terrível. Eu encontrei algumas situações (principalmente onde estávamos migrando ou importando dados para um sistema), onde o uso de um procedimento armazenado era uma rota muito melhor do que escrever um monte de código Java para lidar com a funcionalidade.

Eu acho que a resposta real aqui seria que você deve examinar o que cada procedimento de loja no sistema está fazendo atualmente e avaliá-los caso a caso para determinar se talvez seja mais fácil lidar com a operação em Java ou no banco de dados. Alguns podem muito bem funcionar melhor em Java (pela Biblioteca ORM ou código escrito à mão real), outros não podem. Em ambos os casos, o objetivo sempre deve ser garantir que o sistema seja compreensível e fácil de manter para todos, não apenas se os procedimentos armazenados são bons ou ruins por si só.