Quoi de mieux: string sql ou procédures stockées?

Bit d'un vieil article, mais vaut la peine d'être lu.

https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5766837.html

J'essaierais toujours d'utiliser les procédures stockées, les fonctions, les vues, etc. plutôt que de conserver le SQL dans mes classs d'access aux données.

S'il y a un petit bogue dans le SQL, je trouve qu'il est beaucoup plus facile de changer un proc stocké sur le server SQL que de changer de class et de le rebuild et le déployer.

De plus, il y a l'avantage supplémentaire de la caching et de la security SQL Server.

Ce ne sont pas les deux seules options si vous développez en utilisant C #.

Vous devriez également regarder Entity Framework et NHibernate pour voir ce qu'ils offrent – car ils ont certains avantages au-delà des procédures stockées et des strings SQL.

Quelle que soit la route que vous choisissez, la chose la plus importante est de tout garder séparés. Créez des objects pour représenter vos données et utilisez un référentiel pour interagir avec la database, notamment en transformant datatables dans les objects pour les renvoyer à votre application. Cela signifie que si vous changez d'avis sur les strings SQL, les procédures stockées ou les frameworks ORM – vous n'avez pas besoin d'avoir d'impact sur l'set de votre application – il vous suffira de replace le référentiel.

Motif repoisitoire: http://martinfowler.com/eaaCatalog/repository.html

Entiry Framework: http://msdn.microsoft.com/fr-fr/library/aa697427%28VS.80%29.aspx

NHibernate: http://community.jboss.org/wiki/NHibernateforNET

Ça dépend!

Les SP ont l'avantage d'une meilleure security et de time d'exécution plus rapides. Les cordes bénéficient d'un développement rapide et d'une capacité à effectuer des changements très rapidement.

Pour répondre à votre question, aucun n'est vraiment «meilleur».

Il y a plusieurs aspects à la réponse: la performance, comment réagit-elle aux changements, et à quelle vitesse la nouvelle personne peut-elle comprendre ce qui se passe sans perturber la solution, le time de développement, les tests …

En ce qui concerne les performances, les procédures stockées ont un meilleur time d'exécution car elles sont précompilées et leurs plans d'exécution sont stockés. Le text Sql est compilé chaque fois qu'il est sur le point d'être exécuté (mais la plupart des dbms stockent les plans pour chaque text de requête, donc cet impact n'est pas si drastique).

Dans quelle mesure pouvez-vous maintenir cette solution? J'ai travaillé sur des projets relativement petits (<40 tables), qui avaient des zillions de procédures stockées – c'était vraiment un enfer pour modifier quoi que ce soit puisque vous ne pouvez pas savoir quel autre sp affectera.

Comme pour un mappeur (comme framework d'entité ou similaire), vous devrez d'abord apprendre l'outil, mais ça paye vraiment – pas d'écriture sql, et si votre dbmodel change, le mappeur peut mettre à jour ses entités automatiquement donc il n'y a pas de "nom de colonne invalide" ou des erreurs similaires.

Bottom line est – si vous avez le time de mettre en œuvre un certain ORM. Si vous ne le faites pas, utilisez simplement sql. Utilisez des procédures stockées uniquement dans les opérations critiques.

J'espère que cela aide.

Meilleures salutations

Stackoverflow serait beaucoup mieux s'il y avait une checkbox pour

I need an enterprise class, big boy answer. 

Tant de personnes qui fournissent des réponses démontrent qu'elles ne travaillent pas dans le secteur bancaire ou les services publics, ni dans l'investissement ou la grande dissortingbution ou la fabrication. Par exemple, toutes ces réponses vivent dans un monde simple d'une application par database. La seconde vous ajoutez une certaine complexité, ces solutions montrent leurs verrues. Si votre entreprise a besoin d'une deuxième application pour utiliser cette database, vous devrez forcer cette autre équipe de développement à utiliser votre DAL ou votre ORM. Et s'ils utilisent une technologie qui ne prend pas en charge votre DAL ou votre ORM. En outre, si vous posez cette question, vous n'avez probablement pas le pouvoir de forcer une norme pour les autres équipes.

MAIS

Si l'autre application / technologie vient à votre database, alors ils peuvent accéder à votre database. Si votre CRUD et votre logique de données étaient dans des procédures stockées, CHAQUE application utiliserait la même logique, tout en un seul endroit.

Plusieurs personnes ont dit qu'il était plus rapide d'apporter une modification au code plutôt qu'à la database. Encore une fois, c'est une vue très simplist de SDLC et semble principalement concerné par le développement et non la maintenance. Après avoir quitté votre boîte, il pourrait être déployé sur un millier de posts de travail. Ou 40 servers d'applications. Mais dans la grande majorité des cas, une seule database. (Oui, dans le monde des grands garçons, nous avons aussi dissortingbué des bases de données, mais les applications ne sont presque jamais dans un seul endroit, la plupart des bases de données le sont).

Un répondant a dit que si vous apprenez l'ORM, vous n'aurez jamais besoin d'apprendre le SQL. SQL est une compétence très précieuse, c'est plus que la peine d'apprendre, c'est la vie de tous les développeurs d'affaires. Même les entresockets qui utilisent des bases de données NoSQL utilisent également des bases de données SQL, je vous parie que Facebook et Digg ont un SGBDR pour AR / AP / GL.

Sans oublier l'injection SQL. La meilleure façon d'éviter n'est jamais, jamais de build et d'exécuter dynamicment SQL. Et cela est mieux accompli avec une procédure stockée avec des parameters qui sont dimensionnés et tapés correctement et exécutés comme variables de binding dans le SQL, non concaténées.

Cela dépend de ce que vous voulez atteindre et de la quantité de données impliquées.

De mon expérience personnelle si vous avez de grandes quantités de données et que vous voulez un traitement rapide utiliser SP car il ne recomstack pas chaque instruction SQL chaque fois que vous faites un appel. Cela n'a aucun sens d'implémenter un tas de SP si vous n'avez que de petites quantités de données.

Si vous n'avez pas beaucoup de données qui ont besoin d'un "traitement db en une seule fois", vous pouvez envisager d'utiliser des instructions ORM ou SQL simples, car elles iront probablement mieux dans votre architecture.

Il est également utile de mentionner que lorsque vous utilisez des instructions SQL, les performances et la security gagnent toutes deux à utiliser des requêtes paramétrées .

Une security améliorée est évidente, mais les performances sont également améliorées. Le SGBD (dans le cas de SQL Server) hache le text de la requête (mais pas ses parameters) pour voir s'il a déjà un plan d'exécution.

Si votre requête est paramétrée, la première exécution entraînera la compilation, mais pour la deuxième exécution et les suivantes, le plan d'exécution aura été mis en cache puisque le text de la requête est exactement le même.

D'un autre côté, si votre requête est SQL, chaque exécution peut générer une compilation car chaque requête est légèrement différente.