du code sql dans l'application VB ou bien un appel à une procédure stockée ?

Bonjour

On vient de commencer de developpez en VB 2008 avec sql 2005.

On entend plusieurs opignons sur le fait d'utiliser du code SQL directement dans la l'application VB, ou bien faire un appel à une procédure stockée qui contiendra ce dit code.

Moi je pense que lorsque, on a juste 1 ligne ou deux (un select par exemple) c'est mieux de le faire directement dans l'application VB, mais si on a un grand script SQL dans ce cas il faut le mettre dans une procédure stockée et appelé cette dernière à partir de l'application VB.

Qu'est ce que vous en pensez ? quels sont les pour et les contre ?

Prière au modérateur de mettre ceci en format "débat"

Bonjour,

J'ai lu sur ce forum que le fait d'utiliser des procédure stockées permettait de se prémunir contre des attaques de type "injection SQl" ... (pour ma part derrière mon pare feu ...).
Pour ma part j'ai tendance à utiliser les procédure stockées uniquement lorsque je veux utiliser une requête comme source de données de la deuxième.

Sous access je sais que l'utilisation de procédure stockées permet d'accélérer le traitement, car il s'agit alors de requêtes compilées qui vont plus vite.

A+

Christophe

il n'y a pas de réponses toute faite, les 2 ont des avantages

(au passage on peut éviter l'injection depuis vb aussi via les parameters)

les procédures stockées permettent de sécurisé, car en décompilant le programme .net on ne voit pas la requete et donc la structure de la base
(m'enfin on peut trouver la chaine de connexion en cherchant bien ^^)

niveau perf ca dépend du sgbdr, sql server fait un cache de compilation pour les requetes comme pour les procédures stockées

mettre les requetes dans le code ca permet de devoir recompiler son appli pour les modifier
:aie: ah non ca c'est un inconvénient :lol:


non mais le truc c'est que si on fait tous en procédures stockées, sur des gros projet on peut se retrouver avec des dizaines de milliers de procédures stockées, ce qui n'est pas gérable

après on peut aussi mettre des requête dans une table, avec des regroupements et un éditeur, et là ca devient pas mal


bref c'est selon l'appli ...

Citation:

---

Envoyé par Pol63

il n'y a pas de réponses toute faite, les 2 ont des avantages

(au passage on peut éviter l'injection depuis vb aussi via les parameters)

les procédures stockées permettent de sécurisé, car en décompilant le programme .net on ne voit pas la requete et donc la structure de la base
(m'enfin on peut trouver la chaine de connexion en cherchant bien ^^)

niveau perf ca dépend du sgbdr, sql server fait un cache de compilation pour les requetes comme pour les procédures stockées

mettre les requetes dans le code ca permet de devoir recompiler son appli pour les modifier
:aie: ah non ca c'est un inconvénient :lol:


non mais le truc c'est que si on fait tous en procédures stockées, sur des gros projet on peut se retrouver avec des dizaines de milliers de procédures stockées, ce qui n'est pas gérable

après on peut aussi mettre des requête dans une table, avec des regroupements et un éditeur, et là ca devient pas mal


bref c'est selon l'appli ...

---

Merci bien POL63 pour ces explications.

Selon certaines compagnies, elles ont une règle à suivre et souvent faut juste faire ce que le patron nous demande de faire.

Comme tu dis, il y a des avantages et des inconveinients pour les deux méthodes.

Citation:

---

Envoyé par POL63

au passage on peut éviter l'injection depuis vb aussi via les parameters

---

Tu peux développer un peu plus car si je me sens tranquille derrière le pare feux pro, livrer une appli qui est vulnérable ou qui sert de porte c'est pas génial.

Citation:

---

Envoyé par DEV10

elles ont une règle à suivre et souvent faut juste faire ce que le patron nous demande de faire.

---

Comme là où je bosse le patron c'est moi pour ce genre de sujet la conversation m'intéresse donc sachant que je bosse pas avec SQl Server mais Postgres/postgis et Access 2007.

Concernant l'opposition stockées / SQl direct je fais aussi une distinction au niveaau de accès SGDBR direct (interface) ou par le code. Car il est aussi judicieux (à mon sens) de traiter de grosses requêtes SQL complexes en petites requêtes dont les résultats sont combinés par le code, particulièrement dans le cadre de requête calculées.

je ne vois pas pourquoi tu parles de pare feu ici
un pare feu ca bloque un port de communication réseau

les injections sql c'est quand l'utilisateur entre dans le textbox un morceau de requete qui combiné à une concaténation dans le code vb peut faire qu'il exécute la requete qu'il veut

donc éviter

Code:

---

"select * from table where champ = '" & textbox.text &"'"

---

car si on met dans le textbox ' delete from table select '
ca fait

Code:

---

"select * from table where champ = '' delete from table select ''"

---

mais plutot

Code:

---

"select * from table where champ = @txtsearch"

---

et ajouter un paramètre du nom mis

pour simplifier ca remplace les ' par 2 ' donc le code sql éventuellement mis dans le textbox sera intégré dans la recherche et non exécuté
ac évite donc le problème de l'utilisateur qui marque "l'avion" et qui fait que ca ferme notre '
pour les dates ca gère aussi automatiquement le format de la base, plutot que de faire transiter la date en string pour la remettre en date (norme iso) (et donc d'éviter des inversions jours/mois)



sinon pour les requetes multiples traités dans le code, c'est rarement conseillé, il est toujours plus performant d'écrire des requetes complexes qui font tout, car les données ne transitent pas déjà et ne transitent pas x fois pour rien

Bonsoir,

Visiblement nous ne parlons pas de la même chose, chez moi un pare feux ça sert à autre chose que de seulement bloquer un port réseau, ça analyse tous les paquets entrants et sortants, c'est l'unique gateaway du LAN vers le WEB, ça permet de connexion tunnel SSL ou mieux ... et ça possède des règles notamment en matière "d'injection SQL" ... cf http://www.sonicwall.com/fr/UTM_Firewall_VPN.html

Pour le reste un petit contrôle sur les valeurs introduites dans un InputBox (ou autre flux d'entrée utilisateur) est un minimum.

Concernant "les requêtes traitées par le code" c'est pas tout à fait ce que je voulais dire. Si la modélisation objet est cohérente les méthodes de la couche objet métier peuvent être un palliatif à des requêtes complexes à partir de l'instant ou la population d'une liste d'objet métier est réalisée par requêtes sur la BD sur la base de champs indexés. Les données ne "transitent pas n fois" mais une seule pour initialiser la population d'une liste, puis parcourus une fois pour générer un ou des agrégats.

c'est plus du domaine d'un routeur que d'un pare feu je pense
les FAI ont aussi des routeurs qui analysent les paquets, et ils ne parlent pas de pare feu
m'enfin je ne suis pas expert en sécurité oui ...

d'ailleurs je pense qu'une application .net n'est pas sécurisable, la décompilation étant trop simple

Citation:

---

m'enfin je ne suis pas expert en sécurité

---

Mois non plus mais je suis responsable de la sécurité de mes données ...

Citation:

---

d'ailleurs je pense qu'une application .net n'est pas sécurisable, la décompilation étant trop simple

---

Oui, l'intérêt de vb est le RAD, particulièrement en matière de connectivité au base de donnée et IHM.

Pour revenir à la question initiale je suis d'accord avec toi pour dire que le principal pb des procédures stockées c'est comme pour les variables, le nommage devient rapidement un casse tête à définir et à gérer !