Quand ne pas utiliser ORM et préférer les procédures stockées?

13

J'utilise le micro-ORM PetaPoco. Il est en effet très facile et sécurisé de travailler avec des bases de données à l'aide d'outils ORM, mais la seule chose que je déteste est le code supplémentaire. J'avais l'habitude de mettre la plupart du code dans la base de données elle-même et d'utiliser toutes les fonctionnalités du SGBDR comme les procédures stockées, les déclencheurs, etc., qu'il est conçu pour mieux gérer.

Je veux savoir quand ne pas utiliser ORM sur les procédures / déclencheurs stockés et vice-versa.

orm rdbms stored-procedures

— RPK
source

6

Personnellement, mon problème avec les déclencheurs (en particulier, ne s'applique pas aux procédures stockées) est qu'ils essaient de "deviner" quelle "action commerciale" s'est produite à partir de la façon dont les données sur la base de données sont manipulées. Si vous modifiez la colonne PRICE dans un tableau "ARTICLES", vous ne savez pas vraiment pourquoi . L'utilisateur corrige-t-il simplement une valeur mal saisie? Est-ce une baisse? Est-ce une offre spéciale qui ne dure qu'une journée? Les déclencheurs doivent deviner tout cela.

— Joachim Sauer

16

Les ORM (mappage relationnel-objet) ne s'excluent pas mutuellement avec les procédures stockées. La plupart des ORM peuvent utiliser des procédures stockées. La plupart des ORM génèrent des procédures stockées si vous le souhaitez. Donc, le problème n'est pas non plus ou.

Les ORM peuvent générer du SQL inacceptable (en termes de performances) et vous pouvez parfois vouloir remplacer ce SQL par du SQL fabriqué à la main. L'une des façons d'y parvenir consiste à utiliser des SP (procédures stockées).

Dans DotNet, n'utilisez pas de procédures stockées si:

Si vous n'êtes pas familier avec les procédures stockées (pas votre cas, mais inclus pour être complet).
Si vous ne voulez pas introduire une couche de complexité et de versification à votre projet.
Vous créez une application qui devrait fonctionner avec différentes bases de données ou qui devrait être répliquée sur plusieurs serveurs de base de données (cette dernière restriction peut s'appliquer à certaines bases de données uniquement).

Notez que les déclencheurs ne doivent pas être comparés aux ORM. Les déclencheurs exécutent des fonctions qui ne devraient pas figurer dans le code de votre application (telles que la journalisation ou la synchronisation des données entre les bases de données).

Certaines personnes préfèrent l'utilisation de procédures stockées à SQL dans le code pour différentes raisons telles que la sécurité (par exemple pour empêcher l'injection SQL) et pour leur vitesse revendiquée. Cependant, ceci est quelque peu discutable et nécessite une discussion détaillée.

Si votre ORM ne peut pas générer de procédures stockées et que vous devez écrire un grand système, vous devez peser le codage manuel supplémentaire en fonction de votre cas.

— Aucune chance
source

2

Je crois que l'argument de sécurité n'est pas lié à l'injection SQL, mais plutôt aux autorisations (c'est-à-dire qu'il est principalement simple de gérer les autorisations pour une procédure stockée spécifique pour les utilisateurs qui ont accès à la base de données, mais la gestion de ces autorisations sur les tables, les colonnes et est plus difficile ou impossible). Pourtant, l'argument de la sécurité reste discutable.

— Arseni Mourzenko

@MainMa, merci pour votre commentaire. Ma compréhension est qu'en utilisant des SP, on pourrait réduire le risque d'injection SQL en utilisant une procédure stockée paramétrée avec des paramètres intégrés comme le suggère cet article: palpapers.plynt.com/issues/2006Jun/injection-stored-procedures

— NoChance

2

Les procédures stockées n'ont pratiquement aucun impact sur la vulnérabilité aux attaques par injection SQL. Les vieux mythes meurent dur.

— Rig

@Rig 1, merci pour votre commentaire, je souhaite en savoir plus sur ce que vous en pensez. Ma compréhension vient de ce texte (au moins): "Vous pouvez contrecarrer les attaques par injection SQL Server en utilisant des procédures stockées et des commandes paramétrées, en évitant le SQL dynamique et en restreignant les autorisations sur tous les utilisateurs." qui apparaît dans msdn.microsoft.com/en-us/library/bb669057.aspx

— NoChance

@EmmadKareem SQL paramétré est une grande étape pour le rendre sûr. Je pense que ce gars fait un cas raisonnable palpapers.plynt.com/issues/2006Jun/injection-stored-procedures . Une recherche sur celui-ci "Injection SQL de procédure stockée" fera apparaître beaucoup de hits. Il est toujours bon de désinfecter vos entrées et de nombreuses plates-formes offrent une méthode intégrée pour le faire raisonnablement bien.

— Rig

13

Les ORM supposent souvent que la base de données existe pour servir l'ORM. Mais généralement, la base de données existe pour servir la société, qui peut avoir des centaines et des centaines d'applications écrites dans plusieurs langues.

Mais ce n'est qu'un cas de "ORM vs procédures stockées" si vous utilisez un ORM qui ne peut pas appeler une procédure stockée. Sinon, il s'agit de décider où coder la logique métier.

Où que vous codiez la logique métier, son travail consiste à s'assurer que la base de données passe d'un état cohérent à un autre état cohérent, quelle que soit l'application qui effectue le changement . Vous n'avez donc vraiment que deux choix pratiques: coder une fois dans la base de données ou coder une fois dans une couche d'accès aux données "impénétrable".

Méfiez-vous de l'interface de ligne de commande dbms si vous utilisez un DAL "impénétrable".

— Mike Sherrill 'Cat Recall'
source

4

J'ai rencontré plus d'un cas où d'anciens SP et déclencheurs devaient être utilisés avec de nouvelles applications en raison des applications existantes. L'avantage est que cette logique métier ne doit être maintenue qu'en un seul endroit.

— jfrankcarr

Je ne nie certainement pas que "une seule base de données pour tous les servir" a été utilisée, mais c'est surtout une chose du passé spécifiquement parce que la maintenance devient un enfer, surtout lorsque plusieurs applications ont besoin de maintenir leur propre version des proc stockés. La base de données existe pour servir l'application qui la possède est une approche beaucoup plus moderne car elle impose un couplage plus lâche entre les applications et les services.

— Flater

-1

Requête simple -> ORM

Requête complexe -> Procédure stockée

— Nuit noire
source

3

Où un complexe se sépare-t-il d'une simple requête?

— Indépendant

-2

Le déclencheur doit être utilisé comme invariant d'enregistrement ou se composer de règles commerciales vitales, à mon humble avis.

Les problèmes des ormes:

Vous devez définir des autorisations par tables, pas par "Action" (je veux dire SP)
Pour changer la logique de votre solution, vous devez modifier le code à l'intérieur de votre application, puis le redistribuer sur le réseau pour les clients

— Yuriy Vikulov
source

-5

Être en désaccord. La requête ORM n'est plus simple que si vous connaissez mieux ORM que vous ne connaissez SQL. ORM se traduit par beaucoup plus de code, beaucoup plus difficile à maintenir IMO. Les seules personnes qui bénéficient de l'ORM sont les actionnaires de la société qui vend l'ORM (par exemple Microsoft).

— fantôme
source

1

dommage que l'opinion exprimée dans cette réponse ne soit étayée ni par des références ni par l'expérience. En conséquence, il sera inutile pour un lecteur qui peut tomber sur une revendication "inverse" comme si les procédures stockées ne profitaient qu'aux fournisseurs de bases de données . Elle fait comprendre pourquoi des conseils en vraies questions ont des réponses états: « les vraies questions ont des réponses , pas des articles ou des idées ou opinions ... »

— moucheron