Quais são os prós e os contras de manter o SQL em Stored Procs versus Code [fechado]

https://stackoverflow.com/questions/15142

08-06-2019
|

Pergunta

Quais são as vantagens/desvantagens de manter o SQL em seu código-fonte C# ou em Stored Procs?Tenho discutido isso com um amigo em um projeto de código aberto no qual estamos trabalhando (Fórum C# ASP.NET).No momento, a maior parte do acesso ao banco de dados é feita construindo o SQL embutido em C# e chamando o banco de dados SQL Server.Então estou tentando estabelecer qual seria o melhor para este projeto específico.

Até agora eu tenho:

Vantagens para no código:

Mais fácil de manter – não é necessário executar um script SQL para atualizar consultas
Mais fácil de portar para outro banco de dados - sem procs para portar

Vantagens para processos armazenados:

Desempenho
Segurança

Solução

Não sou fã de procedimentos armazenados

Os procedimentos armazenados são MAIS fáceis de manter porque:* Você não precisa recompilar seu aplicativo C# sempre que quiser alterar algum SQL

Você acabará recompilando-o de qualquer maneira quando os tipos de dados mudarem ou quiser retornar uma coluna extra ou algo assim.O número de vezes que você pode alterar 'transparentemente' o SQL por baixo do seu aplicativo é muito pequeno no geral

Você acaba reutilizando o código SQL.

Linguagens de programação, incluindo C#, têm uma coisa incrível chamada função.Isso significa que você pode invocar o mesmo bloco de código de vários lugares!Incrível!Você pode então colocar o código SQL reutilizável dentro de um deles ou, se quiser obter tecnologia realmente alta, pode usar uma biblioteca que faz isso para você.Acredito que eles são chamados de Mapeadores Relacionais de Objetos e são bastante comuns atualmente.

A repetição de código é a pior coisa que você pode fazer ao tentar construir um aplicativo sustentável!

Concordo, é por isso que os storageprocs são uma coisa ruim.É muito mais fácil refatorar e decompor (dividir em partes menores) código em funções do que SQL em...blocos de SQL?

Você tem 4 servidores web e vários aplicativos Windows que usam o mesmo código SQL. Agora você percebeu que há um pequeno problema com o código SQL, então você prefere......altere o processo em um só lugar ou envie o código para todos os servidores da web, reinstale todos os aplicativos de desktop (clique uma vez pode ajudar) em todas as caixas do Windows

Por que seus aplicativos do Windows estão se conectando diretamente a um banco de dados central?Isso parece uma ENORME falha de segurança e um gargalo, pois exclui o cache do lado do servidor.Eles não deveriam estar se conectando por meio de um serviço da web ou algo semelhante aos seus servidores da web?

Então, enviar 1 novo sproc ou 4 novos servidores web?

Neste caso é é mais fácil enviar um novo sproc, mas, na minha experiência, 95% das 'alterações enviadas' afetam o código e não o banco de dados.Se você estiver enviando 20 itens para os servidores da Web naquele mês e 1 para o banco de dados, dificilmente perderá muito se, em vez disso, enviar 21 itens para os servidores da Web e zero para o banco de dados.

Revisão de código mais fácil.

Você pode explicar como?Eu não entendo isso.Principalmente porque os sprocs provavelmente não estão no controle de origem e, portanto, não podem ser acessados por meio de navegadores SCM baseados na Web e assim por diante.

Mais contras:

Storedprocs residem no banco de dados, que aparece para o mundo exterior como uma caixa preta.Coisas simples como querer colocá-los no controle de origem tornam-se um pesadelo.

Há também a questão do puro esforço.Pode fazer sentido dividir tudo em um milhões de níveis se você está tentando justificar ao seu CEO por que custou apenas 7 milhões de dólares para construir alguns fóruns, mas, caso contrário, criar um procedimento armazenado para cada pequena coisa é apenas um trabalho extra sem nenhum benefício.

Outras dicas

Isso está sendo discutido em alguns outros tópicos aqui atualmente.Sou um defensor consistente de procedimentos armazenados, embora alguns bons argumentos para Linq to Sql estejam sendo apresentados.

Incorporar consultas em seu código vincula você firmemente ao seu modelo de dados.Os procedimentos armazenados são uma boa forma de programação contratual, o que significa que um DBA tem a liberdade de alterar o modelo de dados e o código do procedimento, desde que o contrato representado pelas entradas e saídas do procedimento armazenado seja mantido.

Ajustar bancos de dados de produção pode ser extremamente difícil quando as consultas estão enterradas no código e não em um local central e fácil de gerenciar.

[Editar] Aqui está outro discussão atual

Na minha opinião, você não pode votar sim ou não nesta questão.Depende totalmente do design da sua aplicação.

Voto totalmente contra o uso de SPs em um ambiente de 3 camadas, onde você tem um servidor de aplicação na frente.Nesse tipo de ambiente, seu servidor de aplicativos existe para executar sua lógica de negócios.Se você também usar SPs, você começará a distribuir sua implementação de lógica de negócios por todo o sistema e não ficará muito claro quem é responsável por quê.Eventualmente, você acabará com um servidor de aplicativos que basicamente não fará nada além do seguinte:

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

Então, no final, você tem sua camada intermediária rodando neste cluster muito legal de 4 servidores, cada um deles equipado com 16 CPUs e na verdade não fará nada!Que desperdício!

Se você tem um cliente fat gui que se conecta diretamente ao seu banco de dados ou talvez até mais aplicativos, a história é diferente.Nessa situação, os SPs podem servir como uma espécie de pseudo camada intermediária que separa seu aplicativo do modelo de dados e oferece acesso controlável.

Vantagens para no código:

Mais fácil de manter – não é necessário executar um script SQL para atualizar consultas

Mais fácil de portar para outro banco de dados - sem procs para portar

Na verdade, acho que você entendeu isso ao contrário.IMHO, SQL no código é difícil de manter porque:

você acaba se repetindo em blocos de código relacionados
SQL não é suportado como linguagem em muitos IDEs, então você tem apenas uma série de strings verificadas sem erros executando tarefas para você
mudanças em um tipo de dados, nome de tabela ou restrição são muito mais prevalentes do que trocar um banco de dados inteiro por um novo
seu nível de dificuldade aumenta à medida que sua consulta aumenta em complexidade
e testar uma consulta in-line requer a construção do projeto

Pense nos Stored Procs como métodos que você chama do objeto de banco de dados - eles são muito mais fáceis de reutilizar, há apenas um local para editar e, no caso de você alterar os provedores de banco de dados, as alterações acontecem nos seus Stored Procs e não no seu código .

Dito isto, os ganhos de desempenho dos procs armazenados são mínimos, como Stu disse antes de mim, e você não pode colocar um ponto de interrupção em um procedimento armazenado (ainda).

VIGARISTA

Acho que fazer muito processamento dentro de procedimentos armazenados tornaria seu servidor de banco de dados um ponto único de inflexibilidade, quando se trata de dimensionar seu ato.

No entanto, fazendo toda essa análise em seu programa, em oposição ao sql-server, poder permitem escalar mais se você tiver vários servidores que executam seu código.É claro que isso não se aplica a procs armazenados que apenas fazem a busca ou atualização normal, mas àqueles que realizam mais processamento, como loop em conjuntos de dados.

PRÓS

Desempenho pelo que pode valer (evita análise de consulta por driver de banco de dados/plano de recreação, etc.)
A manipulação de dados não está incorporada no código C/C++/C#, o que significa que tenho menos código de baixo nível para examinar.SQL é menos detalhado e mais fácil de examinar quando listado separadamente.
Devido à separação, as pessoas conseguem encontrar e reutilizar o código SQL com muito mais facilidade.
É mais fácil mudar as coisas quando o esquema muda - você só precisa fornecer a mesma saída ao código e ele funcionará perfeitamente
Mais fácil de portar para um banco de dados diferente.
Posso listar permissões individuais em meus procedimentos armazenados e controlar o acesso nesse nível também.
Posso criar o perfil do meu código de consulta/persistência de dados separado do meu código de transformação de dados.
Posso implementar condições variáveis em meu procedimento armazenado e seria fácil personalizá-lo no local do cliente.
Torna-se mais fácil usar algumas ferramentas automatizadas para converter meu esquema e instruções juntas, em vez de quando elas estão incorporadas em meu código, onde eu teria que procurá-las.
Garantir as melhores práticas para acesso a dados é mais fácil quando você tem todo o seu código de acesso a dados dentro de um único arquivo - posso verificar consultas que acessam a tabela sem desempenho ou aquela que usa um nível mais alto de serialização ou selecionar *'s no código etc. .
Torna-se mais fácil encontrar alterações de esquema/alterações de lógica de manipulação de dados quando tudo está listado em um arquivo.
Torna-se mais fácil pesquisar e substituir edições no SQL quando elas estão no mesmo lugar, por exemplo.alterar/adicionar instruções de isolamento de transação para todos os processos armazenados.
Eu e o DBA descobrimos que ter um arquivo SQL separado é mais fácil/conveniente quando o DBA precisa revisar meu material SQL.
Por último, você não precisa se preocupar com ataques de injeção de SQL porque algum membro preguiçoso da sua equipe não usou consultas parametrizadas ao usar sqls incorporados.

A vantagem de desempenho para procedimentos armazenados é muitas vezes insignificante.

Mais vantagens para procedimentos armazenados:

Evite engenharia reversa (se criada com criptografia, é claro)
Melhor centralização do acesso ao banco de dados
Capacidade de alterar o modelo de dados de forma transparente (sem precisar implantar novos clientes);especialmente útil se vários programas acessam o mesmo modelo de dados

eu caio no código lado.Construímos uma camada de acesso a dados que é usada por todos os aplicativos (web e cliente), portanto, é SECO dessa perspectiva.Isso simplifica a implantação do banco de dados porque só precisamos ter certeza de que os esquemas da tabela estão corretos.Simplifica a manutenção do código porque não precisamos olhar o código-fonte e o banco de dados.

Não tenho muitos problemas com o acoplamento forte com o modelo de dados porque não vejo onde é possível realmente quebrar esse acoplamento.Um aplicativo e seus dados estão inerentemente acoplados.

Procedimentos armazenados.

Se ocorrer um erro ou a lógica mudar um pouco, não será necessário recompilar o projeto.Além disso, permite o acesso de diferentes fontes, não apenas do local em que você codificou a consulta em seu projeto.

Eu não acho que seja mais difícil manter procedimentos armazenados, você não deve codificá-los diretamente no banco de dados, mas primeiro em arquivos separados, então você pode simplesmente executá-los em qualquer banco de dados que você precisa configurar.

Vantagens para procedimentos armazenados:

Revisão de código mais fácil.

Menos acoplado, portanto mais facilmente testado.

Mais facilmente sintonizado.

O desempenho geralmente é melhor, do ponto de vista do tráfego de rede - se você tiver um cursor ou algo semelhante, não haverá várias viagens ao banco de dados

Você pode proteger o acesso aos dados com mais facilidade, remover o acesso direto às tabelas, reforçar a segurança por meio de procs - isso também permite encontrar de forma relativamente rápida qualquer código que atualize uma tabela.

Se houver outros serviços envolvidos (como serviços de relatórios), talvez seja mais fácil armazenar toda a sua lógica em um procedimento armazenado, em vez de em código, e ter que duplicá-la

Desvantagens:

Mais difícil de gerenciar para os desenvolvedores:controle de versão dos scripts:cada um tem seu próprio banco de dados, o sistema de controle de versão está integrado ao banco de dados e ao IDE?

Em algumas circunstâncias, o SQL criado dinamicamente no código pode ter melhor desempenho do que um processo armazenado.Se você criou um processo armazenado (digamos sp_customersearch) que fica extremamente complicado com dezenas de parâmetros porque deve ser muito flexível, você provavelmente poderá gerar uma instrução SQL muito mais simples no código em tempo de execução.

Alguém poderia argumentar que isso simplesmente move algum processamento do SQL para o servidor web, mas em geral isso seria uma coisa boa.

A outra grande vantagem dessa técnica é que, se você estiver procurando no SQL Profiler, poderá ver a consulta gerada e depurá-la com muito mais facilidade do que ver uma chamada de proc armazenada com 20 parâmetros.

Gosto de procs armazenados, não sei quantas vezes consegui fazer uma alteração em um aplicativo usando um procedimento armazenado que não causou nenhum tempo de inatividade no aplicativo.

Grande fã do Transact SQL, o ajuste de consultas grandes provou ser muito útil para mim.Não escrevo nenhum SQL embutido há cerca de 6 anos!

Você lista 2 pontos profissionais para sprocs:

Desempenho - na verdade não.No Sql 2000 ou superior, as otimizações do plano de consulta são muito boas e armazenadas em cache.Tenho certeza de que a Oracle etc. faz coisas semelhantes.Não acho que haja mais motivos para sprocs para desempenho.

Segurança?Por que o sprocs seria mais seguro?A menos que você tenha um banco de dados bastante inseguro, todo o acesso será feito por seus DBAs ou por meio de seu aplicativo.Sempre parametrize todas as consultas - nunca incorpore algo da entrada do usuário e você ficará bem.

De qualquer forma, essa é a melhor prática para desempenho.

Linq é definitivamente o caminho que eu usaria para um novo projeto agora.Veja isso postagem semelhante.

@Keith

Segurança?Por que o sprocs seria mais seguro?

Conforme sugerido por Komradekatz, você pode proibir o acesso às tabelas (para a combinação nome de usuário/senha que se conecta ao banco de dados) e permitir apenas acesso ao SP.Dessa forma, se alguém obtiver o nome de usuário e a senha do seu banco de dados, poderá executar SP's, mas não poderá acessar as tabelas ou qualquer outra parte do banco de dados.

(É claro que a execução de sprocs pode fornecer todos os dados necessários, mas isso dependeria dos sprocs disponíveis.Dar-lhes acesso às tabelas dá-lhes acesso a tudo.)

Pense desta forma

Você tem 4 servidores da web e um monte de aplicativos do Windows que usam o mesmo código SQL agora que você percebeu que há um pequeno problema com o código SQL, então você prefere ......Altere o Proc em 1 local ou empurre o código para todos os servidores da web, reinstale todos os aplicativos de desktop (ClickOnce pode ajudar) em todas as caixas do Windows

Eu prefiro procs armazenados

Também é mais fácil fazer testes de desempenho contra um PROC, coloque -o no conjunto de consultas estatísticas de conjunto io/time no set showplan_text on e pronto

não há necessidade de executar o profiler para ver exatamente o que está sendo chamado

apenas meus 2 centavos

Eu prefiro mantê-los no código (usando um ORM, não inline ou ad-hoc) para que sejam cobertos pelo controle de origem sem ter que salvar arquivos .sql.

Além disso, os procedimentos armazenados não são inerentemente mais seguros.Você pode escrever uma consulta incorreta com um sproc tão facilmente quanto in-line.Consultas embutidas parametrizadas podem ser tão seguras quanto um sproc.

Use o código do seu aplicativo como ele faz de melhor:lidar com a lógica.
Use seu banco de dados para saber o que ele faz de melhor:armazenamento de dados.

Você pode depurar procedimentos armazenados, mas achará mais fácil depurar e manter a lógica no código.Normalmente você terminará de recompilar seu código toda vez que alterar o modelo de banco de dados.

Além disso, procedimentos armazenados com parâmetros de pesquisa opcionais são muito ineficientes porque você precisa especificar antecipadamente todos os parâmetros possíveis e pesquisas complexas às vezes não são possíveis porque você não pode prever quantas vezes um parâmetro será repetido na pesquisa.

Quando se trata de segurança, os procedimentos armazenados são muito mais seguros.Alguns argumentaram que todo o acesso será feito por meio do aplicativo de qualquer maneira.O que muitas pessoas esquecem é que a maioria das violações de segurança vem de dentro da empresa.Pense em quantos desenvolvedores conhecem o nome de usuário e a senha "ocultos" do seu aplicativo?

Além disso, como MatthieuF apontou, o desempenho pode ser muito melhorado devido a menos viagens de ida e volta entre o aplicativo (seja em um desktop ou servidor web) e o servidor de banco de dados.

Na minha experiência, a abstração do modelo de dados através de procedimentos armazenados também melhora enormemente a capacidade de manutenção.Como alguém que teve que manter muitos bancos de dados no passado, é um grande alívio quando confrontado com uma mudança de modelo necessária poder simplesmente alterar um ou dois procedimentos armazenados e fazer com que a mudança seja completamente transparente para TODOS os aplicativos externos.Muitas vezes sua aplicação não é a única apontada para um banco de dados - existem outras aplicações, soluções de relatórios, etc.portanto, rastrear todos os pontos afetados pode ser um incômodo com acesso aberto às mesas.

Também colocarei marcas na coluna mais para colocar a programação SQL nas mãos de quem se especializa nela e para SPs, tornando muito mais fácil isolar e testar/otimizar o código.

A única desvantagem que vejo é que muitas linguagens não permitem a passagem de parâmetros de tabela, portanto, passar valores de dados numéricos desconhecidos pode ser irritante, e algumas linguagens ainda não conseguem recuperar vários conjuntos de resultados de um único procedimento armazenado (embora o o último não torna os SPs piores do que o SQL embutido nesse aspecto).

Uma das sugestões de uma sessão do Microsoft TechEd sobre segurança da qual participei, é fazer todas as chamadas através de procs armazenados e negar acesso diretamente às tabelas.Essa abordagem foi considerada como fornecendo segurança adicional.Não tenho certeza se vale a pena apenas por segurança, mas se você já estiver usando procs armazenados, não fará mal.

Definitivamente mais fácil de manter se você colocá-lo em um procedimento armazenado.Se houver uma lógica difícil envolvida que poderá mudar no futuro, é definitivamente uma boa ideia colocá-la no banco de dados quando você tiver vários clientes conectados.Por exemplo, estou trabalhando em um aplicativo agora que possui uma interface web de usuário final e um aplicativo de desktop administrativo, ambos compartilhando um banco de dados (obviamente) e estou tentando manter o máximo de lógica possível no banco de dados.Este é um exemplo perfeito do Princípio SECO.

Estou firmemente do lado dos procs armazenados, presumindo que você não trapaceie e use SQL dinâmico no proc armazenado.Primeiro, o uso de procs armazenados permite que o dba defina permissões no nível do proc armazenado e não no nível da tabela.Isso é fundamental não apenas para combater ataques de injeção de SQL, mas também para impedir que pessoas internas acessem diretamente o banco de dados e alterem as coisas.Essa é uma forma de ajudar a prevenir fraudes.Nenhum banco de dados que contenha informações pessoais (SSNs, números de cartão de crédito, etc.) ou que de alguma forma crie transações financeiras deve ser acessado, exceto através de procedimentos rigorosos.Se você usar qualquer outro método, estará deixando seu banco de dados aberto para que indivíduos da empresa criem transações financeiras falsas ou roubem dados que podem ser usados para roubo de identidade.

Os procs armazenados também são muito mais fáceis de manter e ajustar o desempenho do que o SQL enviado do aplicativo.Eles também permitem ao dba ver qual será o impacto de uma mudança estrutural no banco de dados na forma como os dados são acessados.Nunca conheci um bom dba que permitisse acesso dinâmico ao banco de dados.

Usamos procedimentos armazenados com bancos de dados Oracle onde trabalho agora.Também usamos o Subversion.Todos os procedimentos armazenados são criados como arquivos .pkb e .pks e salvos no Subversion.Já fiz SQL in-line antes e é uma dor!Prefiro muito mais a maneira como fazemos aqui.Criar e testar novos procedimentos armazenados é muito mais fácil do que fazer isso no seu código.

Há um

Registros menores

Outro pequeno profissional para procedimentos armazenados que não foi mencionado:quando se trata de tráfego SQL, o acesso a dados baseado em SP gera muito menos tráfego.Isso se torna importante quando você monitora o tráfego para análise e criação de perfil – os logs serão muito menores e legíveis.

Não sou um grande fã de procedimentos armazenados, mas os uso com uma condição:

Quando a consulta é muito grande, é melhor armazená-la no banco de dados como um procedimento armazenado em vez de enviá-la a partir do código.Dessa forma, em vez de enviar grandes quantidades de caracteres string do servidor de aplicação para o banco de dados, apenas o "EXEC SPNAME" comando será enviado.

Isso é um exagero quando o servidor de banco de dados e o servidor web não estão na mesma rede (por exemplo, comunicação pela Internet).E mesmo que não seja esse o caso, muito estresse significa muito desperdício de largura de banda.

Mas cara, eles são tão terríveis de administrar.Eu os evito tanto quanto posso.

Um processo armazenado SQL não aumenta o desempenho da consulta

Bem, obviamente, o uso de procedimentos armazenados tem várias vantagens sobre a construção de SQL no código.

A implementação do seu código e o SQL tornam-se independentes um do outro.
O código é mais fácil de ler.
Escreva uma vez e use muitas vezes.
Modifique uma vez
Não há necessidade de fornecer detalhes internos ao programador sobre o banco de dados.etc etc.

Procedimentos armazenados são MAIS sustentável porque:

Você não precisa recompilar seu aplicativo C# sempre que quiser alterar algum SQL
Você acaba reutilizando o código SQL.

A repetição de código é a pior coisa que você pode fazer ao tentar criar um aplicativo sustentável!

O que acontece quando você encontra um erro lógico que precisa ser corrigido em vários lugares?É mais provável que você esqueça de alterar o último local onde copiou e colou seu código.

Na minha opinião, os ganhos de desempenho e segurança são uma vantagem adicional. Você ainda pode escrever procedimentos armazenados SQL inseguros/ineficientes.

Mais fácil de portar para outro banco de dados - sem procs para portar

Não é muito difícil criar scripts de todos os seus procedimentos armazenados para criação em outro banco de dados.Na verdade - é mais fácil do que exportar suas tabelas porque não há chaves primárias/estrangeiras com que se preocupar.

@Terrapin - sprocs são igualmente vulneráveis a ataques de injeção.Como eu disse:

Sempre parametrize todas as consultas - nunca incorpore algo da entrada do usuário e você ficará bem.

Isso vale para sprocs e SQL dinâmico.

Não tenho certeza se não recompilar seu aplicativo seja uma vantagem.Quero dizer, você executou seus testes de unidade nesse código (aplicativo e banco de dados) antes de entrar no ar novamente.

@Guy - sim, você está certo, os sprocs permitem controlar os usuários do aplicativo para que eles possam executar apenas o sproc, não a ação subjacente.

Minha pergunta seria:se todos acessam através do seu aplicativo, usando conexões e usuários com direitos limitados para atualizar/inserir etc., esse nível extra adiciona segurança ou administração extra?

Minha opinião é basicamente esta última.Se eles comprometeram seu aplicativo a ponto de poder reescrevê-lo, eles terão muitos outros ataques que poderão usar.

As injeções de SQL ainda podem ser executadas nesses sprocs se eles incorporarem o código dinamicamente, portanto, a regra de ouro ainda se aplica: todas as entradas do usuário devem sempre ser parametrizadas.

Algo que não vi mencionado até agora:as pessoas que melhor conhecem o banco de dados nem sempre são as que escrevem o código do aplicativo.Os procedimentos armazenados fornecem ao pessoal do banco de dados uma maneira de interagir com programadores que realmente não querem aprender muito sobre SQL.Bancos de dados grandes - e especialmente legados - não são as coisas mais fáceis de entender completamente, então os programadores podem preferir apenas uma interface simples que lhes forneça o que precisam:deixe os DBAs descobrirem como unir as 17 tabelas para que isso aconteça.

Dito isto, as linguagens usadas para escrever procedimentos armazenados (sendo PL/SQL um exemplo notório) são bastante brutais.Eles normalmente não oferecem nenhuma das sutilezas que você veria nas linguagens imperativas, OOP ou funcionais populares de hoje.Pense em COBOL.

Portanto, opte por procedimentos armazenados que apenas abstraem os detalhes relacionais, em vez daqueles que contêm lógica de negócios.

Geralmente escrevo código OO.Suspeito que a maioria de vocês provavelmente também.Nesse contexto, parece-me óbvio que toda a lógica de negócios - incluindo consultas SQL - pertence às definições de classe.Dividir a lógica de forma que parte dela resida no modelo de objeto e parte no banco de dados não é melhor do que colocar lógica de negócios na interface do usuário.

Muito foi dito em respostas anteriores sobre os benefícios de segurança dos processos armazenados.Eles se enquadram em duas categorias amplas:

1) Restringir o acesso direto aos dados.Definitivamente, isso é importante em alguns casos e, quando você encontrar um, os procs armazenados serão praticamente sua única opção.Na minha experiência, no entanto, tais casos são a exceção e não a regra.

2) Injeção SQL/consultas parametrizadas.Esta objeção é uma pista falsa.O SQL embutido - até mesmo o SQL embutido gerado dinamicamente - pode ser tão totalmente parametrizado quanto qualquer processo armazenado e pode ser feito com a mesma facilidade em qualquer linguagem moderna que se preze.Não há vantagem de qualquer maneira aqui.("Desenvolvedores preguiçosos podem não se preocupar em usar parâmetros" não é uma objeção válida.Se você tem desenvolvedores em sua equipe que preferem apenas concatenar os dados do usuário em seu SQL em vez de usar parâmetros, primeiro você tenta educá-los e depois os demite se isso não funcionar, assim como faria com desenvolvedores que têm qualquer outro hábito ruim e comprovadamente prejudicial.)

Sou um grande defensor do código em vez do SPROC.O principal motivo é manter o código firmemente acoplado; em segundo lugar, está a facilidade do controle de origem sem muitos utilitários personalizados para extraí-lo.

Em nosso DAL, se tivermos instruções SQL muito complexas, geralmente as incluímos como arquivos de recursos e as atualizamos conforme necessário (isso também pode ser um assembly separado e trocado por banco de dados, etc...).

Isso mantém nosso código e nossas chamadas sql armazenadas no mesmo controle de versão, sem “esquecer” de rodar algumas aplicações externas para atualização.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow