Quando não usar o ORM e preferir procedimentos armazenados?

13

Estou usando o PetaPoco micro-ORM. É realmente muito fácil e seguro trabalhar com bancos de dados usando ferramentas ORM, mas a única coisa que odeio é o código extra. Eu costumava colocar a maior parte do código no próprio banco de dados e usar todos os recursos do RDBMS, como procedimentos armazenados, gatilhos etc., que foram criados para lidar melhor.

Quero saber quando não usar o ORM em procedimentos armazenados / gatilhos e vice-versa.

orm rdbms stored-procedures

— RPK
fonte

6

Pessoalmente, meu problema com gatilhos (em particular, não se aplica a procedimentos armazenados) é que eles tentam "adivinhar" qual "ação comercial" aconteceu com a forma como os dados no banco de dados são manipulados. Se você modificar a coluna PRICE em uma tabela "ARTICLES", não saberá realmente por que. O usuário está apenas corrigindo um valor digitado incorretamente? Isso é uma redução? É uma oferta especial que dura apenas um dia? Os gatilhos precisam adivinhar tudo isso.

— Joachim Sauer

16

ORMs (mapeamento objeto-relacional) não são mutuamente exclusivos com procedimentos armazenados. A maioria dos ORMs pode utilizar procedimentos armazenados. A maioria dos ORMs gera procedimentos armazenados, se você preferir. Portanto, a questão não é ou.

Os ORMs podem gerar SQL inaceitável (em termos de desempenho) e, às vezes, você pode substituir esse SQL pelo SQL artesanal. Uma das maneiras de conseguir isso é usando SPs (procedimentos armazenados).

No DotNet, não use procedimentos armazenados se:

Se você não estiver familiarizado com os procedimentos armazenados (não é o seu caso, mas incluídos para fins completos).
Se você não quiser introduzir uma camada de complexidade e versatilidade ao seu projeto.
Você está criando um aplicativo que deve funcionar com bancos de dados diferentes ou que precisaria ser replicado em vários servidores de banco de dados (essa última restrição pode ser aplicada apenas a alguns bancos de dados).

Observe que os gatilhos não devem ser comparados com ORMs. Os gatilhos executam funções que não são melhores no código do aplicativo (como registrar ou sincronizar dados nos bancos de dados).

Algumas pessoas preferem o uso de procedimentos armazenados em vez de SQL no código por diferentes razões, como segurança (por exemplo, para impedir a injeção de SQL) e pela velocidade reivindicada. No entanto, isso é um tanto discutível e precisa de discussão detalhada.

Se o seu ORM não puder gerar procedimentos armazenados e você precisar escrever um sistema grande, será necessário ponderar a codificação manual extra com base no seu caso.

— NoChance
fonte

2

Acredito que o argumento de segurança não esteja relacionado à injeção de SQL, mas às permissões (ou seja, é mais direto gerenciar permissões para um procedimento armazenado específico para os usuários que têm acesso ao banco de dados, mas gerenciar essas permissões em tabelas, colunas e linhas é mais difícil ou impossível). Ainda assim, o argumento de segurança permanece discutível.

— Arseni Mourzenko 12/03/12

@MaMaMa, obrigado pelo seu comentário. Meu entendimento é que usando SPs, pode-se reduzir o risco de injeção de SQL pelo uso de procedimento armazenado parametrizado com parâmetros incorporados, como este artigo sugere: palpapers.plynt.com/issues/2006Jun/injection-stored-procedures

— NoChance

2

Os procedimentos armazenados praticamente não têm impacto na vulnerabilidade a ataques de injeção de sql. Velhos mitos morrem com força.

— Rig

@ Rig 1, obrigado pelo seu comentário, desejo aprender mais sobre o que você pensa disso. Meu entendimento vem deste texto (pelo menos): "Você pode impedir ataques de injeção do SQL Server usando procedimentos armazenados e comandos parametrizados, evitando o SQL dinâmico e restringindo as permissões de todos os usuários". que aparece em msdn.microsoft.com/en-us/library/bb669057.aspx

— NoChance 04/04

@EmmadKareem O sql parametrizado é um grande passo para torná-lo seguro. Eu acho que esse cara faz um caso razoável palpapers.plynt.com/issues/2006Jun/injection-stored-procedures . Uma pesquisa nele "Injeção de SQL de procedimento armazenado" exibirá muitas ocorrências. É sempre bom higienizar suas entradas e muitas plataformas fornecem uma maneira integrada de fazê-lo razoavelmente bem.

— Rig

13

Os ORMs geralmente assumem que o banco de dados existe para atender ao ORM. Mas geralmente o banco de dados existe para atender a empresa, que pode ter centenas e centenas de aplicativos escritos em vários idiomas.

Mas é apenas um caso de "ORM vs. procedimentos armazenados" se você estiver usando um ORM que não pode chamar um procedimento armazenado. Caso contrário, é um caso de decidir onde codificar a lógica de negócios.

Onde quer que você codifique a lógica de negócios, seu trabalho é garantir que o banco de dados mude de um estado consistente para outro estado consistente, independentemente de qual aplicativo faz a alteração . Então, você realmente só tem duas opções práticas - codifique uma vez no banco de dados ou uma vez em uma camada de acesso a dados "impenetrável".

Cuidado com a interface da linha de comandos do dbms se você usar um DAL "impenetrável".

— Mike Sherrill 'Recorde Gato'
fonte

4

Já deparei com mais de um caso em que SPs e gatilhos antigos precisavam ser usados com novos aplicativos por causa dos aplicativos herdados existentes. A vantagem é que essa lógica de negócios só precisa ser mantida em um só lugar.

— jfrankcarr

Definitivamente, não estou negando que "um banco de dados para servir a todos" tenha sido usado, mas isso é uma coisa do passado, especificamente porque a manutenção se torna um inferno, especialmente quando vários aplicativos precisam manter sua própria versão de procs armazenados. A existência do banco de dados para atender ao aplicativo que o possui é uma abordagem muito mais moderna, pois impõe um acoplamento mais flexível entre aplicativos e serviços.

— Flater

-1

Consulta simples -> ORM

Consulta complexa -> Procedimento armazenado

— Noite escura
fonte

3

Onde é que a segregar complexa desde uma simples consulta,

— Independent

-2

O gatilho deve ser usado como invariável de registro ou consistir em regras comerciais vitais, IMHO.

Os problemas das orms:

Você deve definir permissões por tabelas, não por "Ação" (quero dizer SP)
Para alterar a lógica da sua solução, você precisa alterar o código dentro do seu aplicativo e depois redistribuí-lo pela rede para clientes

— Yuriy Vikulov
fonte

-5

Discordo. A consulta ORM é mais simples, se você conhece o ORM melhor do que o SQL. O ORM resulta em muito mais código, muito mais difícil de manter a IMO. As únicas pessoas que se beneficiam do ORM são os acionistas da empresa que vende o ORM (por exemplo, Microsoft).

— fantasma
fonte

1

pena que a opinião expressa nesta resposta não seja apoiada nem por referências nem por experiência. Como resultado, será inútil para um leitor que possa se deparar com uma reivindicação "inversa", como procedimentos armazenados, beneficiando apenas os fornecedores de DB . Faz perceber por que a orientação em questões reais têm respostas estados: "verdadeiras questões têm respostas , não itens ou idéias ou opiniões ... "

— mosquito