Discussion :

[CUCARACHA]

Salut à tous,

J'ai récemment été confronté à un développeur qui ne jurait que par le Dataset. Personnellement, connaissant bien SQL Server, je préfère déporter tout les traitements touchant aux données dans la base.

Ce développeur m'a expliqué que les chaines SQL stockées dans le Dataset étaient des procédures stockées, or, elles n’apparaissent pas en tant que telles dans la base.

Je n'aime pas beaucoup les composants de type Dataset car je considère que l'on perd trop le contrôle de l'application et qu'il devient difficile de l'optimiser une fois qu'elle est terminée.

Cela m'amène à me pauser les questions suivantes ?

Dataset / procédures stockées, qui est pour et qui est contre ?

Considérez-vous que le dataset soit une couche de persistance comme NHibernate ?

Pensez-vous qu'une boucle de mise à jour en cascade puisse être plus performante avec le Dataset plutôt qu'avec des bonnes vielles procédures stockées bien optimisées ?

L'objectif n'est pas de troller mais de savoir si la tendance penche en faveur de l'une ou l'autre des technologies.

D'avance merci pour vos participations...

Laurent

[ccambier]

salut,
je trouve que ce sondage est assez interressant...

connaissant très sql server, je trouve aussi qu'une bonne procedure s'avère souvent efficace, et que ça permet de partager le travail entre le client et le serveur.
je trouve aussi que ça peut dépendre des cas d'applications, la procedure engage un lien, meme une dépendance avec le server sql, alors que le dataset permet une compléte indépendance.

ce que j'ai personnellement plus tendance à faire c'est d'utiliser une procédure ou une vue avec une DataTable, ou alors un objet semblable au schéma de la table et en faire une collection, ce que je trouve beaucoup plus souple et nettement plus facile à optimiser.

pour moi le DataSet est une bonne chose à utiliser avec modération...

[jdc]

J'utilise exclusivement des procédures stockées.
D'après ce que je comprends à propos du dataset, cela permet de garder en mémoire le résultat d'un query et donc au final de pouvoir lancer de nouvelles consultes sur le dataset lui-même (sans retourner au serveur sql).
Généralement je n'ai pas besoin de retravailler les données que je vais chercher dans le serveur sql. Donc je n'y vois pas trop d'intérêt. Mais par contre, je suis curieux d'entendre d'autres témoignagnes.

[CUCARACHA]

Salut,

Merci de participer... @+


LJ

[nashouille]

bonjour,

je ne vois pas ou est le probleme en sachant que l"un va avec l'autre.

le dataset est tres performant lors de l'utilisation de WebService.
le dataset s'utilise tres bien avec des procedures stockée.
le dataset est une copie memoire pour evité les transactions continuel avec le SGDB utilisé.

l'utilité de la séparation du chainage sql du code est pour ma part evidente (meilleur vision dans les couches metier).


Je pense que suivant le projet et la reflexion du developpeur, tout les solutions doivent etres envisagée pour memé à terme une performance maximal d'utilisation, de suivi et de mise a jour dans le projet.

pose toi la bonne question, que m'apporte le dataset en plus de ma procédure stockée et non pas l'un ou l'autre.

Cordialement
Frederic

[Maniak]

Ce développeur m'a expliqué que les chaines SQL stockées dans le Dataset étaient des procédures stockées, or, elles n’apparaissent pas en tant que telles dans la base.

Ben soit je ne comprends pas ce qu'il dit (fin de semaine, tout ça), soit il dit n'importe quoi...

Je n'aime pas beaucoup les composants de type Dataset car je considère que l'on perd trop le contrôle de l'application et qu'il devient difficile de l'optimiser une fois qu'elle est terminée.

Normal, les DataSet (notamment typés) sont des usines à gaz dans le plus pur sens du terme.

Dataset / procédures stockées, qui est pour et qui est contre ?

On a droit à une 3è option ? Ni l'un ni l'autre pour peu que la taille et le timing du projet le permettent. Du moins ni l'un ni l'autre exclusivement.

DataSet, c'est facile, c'est rapide, c'est via le designer, pour des projets vite faits, ça va très bien. C'est laid, c'est lourd, c'est couplé dans tous les sens possibles et imaginables, mais ça va vite.

Les sprocs exclusivement, c'est utile quand on a un process de mise en prod bien lourdingue avec un ou des DBAs bien radicaux qui tiennent absolument à ce que tout passe par eux.

Les librairies ORM, que ce soit via NHibernate, un truc fait main ou n'importe quelle autre librairie, ça permet 1/ de continuer à utiliser des sprocs si c'est vraiment nécessaire (ça arrive, mais c'est loin d'être aussi fréquent que certains aimeraient le faire croire), 2/ que le code 'client' utilise directement des objets bien formés, avec les informations nécessaires et pas des objets lourdingues non-typés, ou typés mais du coup il n'y a plus de mot pour exprimer leur lourdeur, qui font tout sauf le café. On peut toujours passer par des DataSets et des sprocs pour obtenir ces objets bien formés, mais ça s'arrête là.

Considérez-vous que le dataset soit une couche de persistance comme NHibernate ?

Non. Le DataSet est un objet qui peut servir dans une couche d'accès aux données, mais quand il est utilisé depuis l'accès aux données jusqu'à l'interface, on oublie les notions de couche. Ça n'existe plus.

Pensez-vous qu'une boucle de mise à jour en cascade puisse être plus performante avec le Dataset plutôt qu'avec des bonnes vielles procédures stockées bien optimisées ?

Je pense plutôt que les performances ne sont pas à prendre en compte à ce niveau. Que ce soit via sprocs, DataSet ou librairie, les mises à jour sont de toutes façons gérables de manière suffisamment performante (sauf cas particuliers qui nécessitent des considérations particulières). La grande question après est celle de la lisibilité, de la clarté du code, de la facilité de maintenance, plein de choses super pointues de ce genre. Les DataSets sont immondes pour ça, les sprocs nettement moins, mais à part le cas d'une base attaquée par plein d'applications sur plein de plate-formes différentes et qui a besoin d'appliquer les mêmes règles métier partout, tout caser dans des sprocs n'est vraiment pas mon truc.

Je suis tombé depuis un moment dans le camp du domain-driven design. Le plus important est que le code 'qui fait le boulot' parle à des objets qui représentent correctement le domaine. Les DataSets ne représentent rien. Ce sont des bacs à ***** qui stockent tout et n'importe quoi. De ce côté-là, poubelle.
Les sprocs sont gérées en-dehors du code, doivent passer par des procédures plus ou moins tordues pour être publiées, sont légèrement plus délicates à mettre sous contrôle de code source (et à maintenir synchros avec le code de l'appli), sont plus difficiles à tester en isolation de manière automatique (et pas en même temps que le reste du code de l'application), sont plus pratiques pour gérer les permissions mais n'apportent aucun gain de performance (c'est fini depuis SQL2k ça)
Les couches d'ORM faites main ou les librairies à la NHibernate demandent un temps d'apprentissage non-négligeable, pas applicable à tous les projets, loin de là, mais permettent de s'éloigner de ces problèmes. Certes il faut continuer de faire attention au SQL généré. Certes il faut surveiller de près ce qui est généré comme jointures, les tailles de batchs, faire des requêtes sur-mesure le cas échéant, continuer à passer par des sprocs si besoin (notamment pour les règles métier qui doivent être mises dans la base). Au moins, il y a le choix, on fait ce qu'on veut, l'essentiel est qu'en sortie on traite des objets représentant le domaine.

Bref, mon avis perso est que les DataSets purs, c'est bien quand on est pressé et/ou qu'on doit faire du jetable. Sur du plus long terme, c'est une abomination pour ceux qui doivent se taper ça derrière (j'en sors d'il y a très peu de temps, le cauchemar est encore tout frais).
La version exclusivement sprocs, pas mieux. Il faut aimer les procédures super lourdes (procédures 'administratives', paperasse, tout ça, pareil, j'en sors tout fraîchement) pour avoir un vague espoir que ce soit géré correctement. Si ça peut l'être, très bien. Si c'est le boxon niveau organisation côté DBA et synchro côté dev et que les applis ayant besoin des mêmes règles métier partagent la même techno, autant que la couche *métier* gère les règles *métier* plutôt que de les dispatcher comme ça.
La version librairie ORM (toute faite ou faite main si on a *beaucoup* de temps), c'est vraiment le meilleur des deux mondes. Pour le cas où on a le temps de s'y mettre.

Autrement dit, je suis tout autant allergique aux DataSets (typés ou non. limite je préfère les non-typés) qu'au 100% sprocs. 4 sprocs mini par table pour faire un select, un insert, un update et un delete, en plus des vraies sprocs vraiment utiles, oui mais non quoi... J'ai beau être passé sur des projets où c'était la seule façon de faire, c'était plus un problème d'organisation du projet qu'un avantage lié à l'utilisation des sprocs.

Maintenant dans tous les cas, comme d'hab, ça dépend du projet, de son envergure et de l'organisation qu'il y a autour. Pas de magie.