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

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.

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.

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".

Consulta simples -> ORM

Consulta complexa -> Procedimento armazenado

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

Os problemas das orms:

1. Você deve definir permissões por tabelas, não por "Ação" (quero dizer SP)
2. 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

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).