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.

[Kelpan]

Entièrement d'accord avec Maniak.
La DataSet est une pure usine à gaz.
Nous l'avons banni de tout développement.

Perso, je passe par mes propres classes de mappage alimentées par DataReader et une par procs stockée pour INSERT/UPDATE/DELETE.

[dinbougre]

Chouette, moi qui me posait des questions existentielles sur les Dataset.... Je pense avoir une réponse qui me confirmait mes pensées....

J'ai pas une vue assez profonde du Dataset donc je ne savais pas trop comment faire pour démarrer sur un projet actuel où m'a dit d'utiliser tous les objets proposées par le framework .net 2.0... "Ne pas réinventer la roue". Ca me disait pas trop mais sans pouvoir vraiment argumenter.

Dans le même ordre, est ce que ce raisonnement s'applique aussi à la gestion des rôles par asp.net... Pcq c'est aussi l'impression que j'ai eu concernant la création d'un menu (via les contrôles asp.net avec un sitemap) et de gérer les accès selon le rôle du user dans Active Directory... Certes c'est super rapide et ça marche pas trop mal, mais j'ai tjrs peur de l'usine à gaz derrière.

Mais sur un tel raisonnement, autant tout développer soi même et poubelle les outils proposés par microsoft...

[CUCARACHA]

Salut,

Il ne faut pas que tu te méprennes sur les propos que nous avons tenus et surtout, il ne faut pas que tu les généralises...

En fait, la gestion des rôles et la gestion des utilisateur est sans doute l'un des plus gros avantages de l'asp.net dans le framework 2.0. C'est pas du tout une usine à gaz, bien au contraire.

Je te conseille vivement de bien l'étudier avant de commencer ton projet. Ca vaut le coup. En fait, je crois que c'est quasiment le seul moyen de vraiment sécuriser un site web.

L'astuce est de ne surtout pas faire comme certains ex-développeurs du client lourd qui on tendance à tout fourrer dans une seule page. Les pages Web, furent-elles ASP.net se doivent d'être légères et réparties dans des répertoires. La gestion des rôles et des utilisateurs est parfaitement conçue pour gérer un site web très complexe. De plus, il est possible de choisir entre plusieurs modes de stockage des informations des comptes, y compris (avec un peu plus de travail) dans l'active directory.

En fait il faut créer un répertoire par bloc fonctionnel, par exemple, la gestion des produits. Ensuite, tu peux faire deux sous répertoires, l'un pour l'administration, réservé à une catégorie d'utilisateurs et l'autre pour la consultation ou l'utilisation, réservée à un autre groupe. L'administration de tout ça est parfaitement intégrée dans la page d'administration du site. C'est des heures et des heures de boulot d'économisées.

Concernant les dataset et les procédures stockées, je dirais que les Datasets sont préférables si l'on a pas un excellent niveau en SQL Server. Il y a de nombreuses sécurités qui renforcent la solidité de l'application. Les procédures stockées sont plus performantes mais nécessitent beaucoup plus d'expérience. A toi d'étudier les deux méthodes avant d'en choisir une.

Personnellement, et malgré mes choix, je te dirais que si tu n'as encore jamais pratiqué l'une ou l'autre, concentres toi sur les Dataset car c'est un premier pas vers une architecture à persistance objet qui est la voie royale pour travailler sur de gros projets très complexes.

++

Laurent

[Keihilin]

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

Il dit n'importe quoi...

Ce genre de vaste débat a souvent lieu entre architectes...Il y a les intégristes qui voient une base de données comme un simple "magasin" pour leur objets ou au contraire les objets comme un simple moyen d'exposer les précieuses données...
La question sous-jacente étant souvent : "ou dois-je placer ma logique métier ?"

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)

Ok, mais les procédures assurent la sécurité des données, sont plus fiables en terme transactionnel et peuvent apporter un gain significatif de perfs selon le type de base et les options disponibles (compilation des sprocs par exemple).

Concernant la synchronisation avec le code de l'appli, je ne suis pas d'accord. Une BDD qui expose des procédures permettra beaucoup plus facilement de rendre les modifications internes transparentes pour l'application.

Pour répondre à la question du débat, je ne suis pas spécialement un fanatique des procédures (bien que je sois contre les datasets), mais je suis bien obligé de constater que l'élément primordial dans bon nombre de projets reste la base de données (projets bancaires notamment), et partant de là, les procédures stockées restent le meilleur compromis.

[dinbougre]

En fait, la gestion des rôles et la gestion des utilisateur est sans doute l'un des plus gros avantages de l'asp.net dans le framework 2.0. C'est pas du tout une usine à gaz, bien au contraire.Laurent

Ok, effectivement si on regarde tous les composants fournis par le framework DotNet 2.0 il y a de quoi faire rapidement un site et très facilement (dataset, formview, gridview, menu, etc...). Mais après ce qui me fait toujours peur c'est d'avoir tous ces contrôles qui font ce que je veux mais eventuellement beaucoup plus (la peur de l'usine à gaz). Mais concernant les rôles faut que je planches un peu plus dessus

Actuellement on m'impose d'utiliser autant que possible les possibilités du framework 2.0, donc ça sera une très bonne expérience pour voir les + et -.

[Maniak]

Ok, mais les procédures assurent la sécurité des données, sont plus fiables en terme transactionnel et peuvent apporter un gain significatif de perfs selon le type de base et les options disponibles (compilation des sprocs par exemple).

À adapter selon les domaines, besoins et utilisations. Des fois elles ont des avantages importants, des fois c'est totalement négligeable, des fois c'est carrément négatif.

Concernant la synchronisation avec le code de l'appli, je ne suis pas d'accord. Une BDD qui expose des procédures permettra beaucoup plus facilement de rendre les modifications internes transparentes pour l'application.

Faut voir le genre de modifications. Si c'est au niveau du fonctionnement interne des opérations, ok. Si c'est lié à des changements de structure qui se répercutent de toute façon dans l'appli, ça fait juste un 2è endroit sur lequel les appliquer. Si c'est lié à des changements dans la logique métier... ben ça veut dire que la logique métier est éparpillée entre l'appli et les sprocs (peu de chances que rien de soit dans l'appli), donc même si c'est plus pratique de ce côté-là, ça fait quand même 2 endroits où aller chercher les infos quand on veut savoir comment un truc fonctionne (et/ou le modifier), 2 endroits à tenir synchros quand les comportements sont liés, etc.

Comme dit plus haut, si la base est attaquée par plein d'applis dans des technos différentes, là même la logique métier dans les sprocs est nettement plus intéressant. Plus elle est localisée dedans, moins elle est dupliquée dans chaque appli. Par contre s'il n'y a qu'une appli, plusieurs applis partageant une même techno (donc partage de librairies), ou des règles indépendantes pour chaque, moins d'intérêt. Dans ce cas-là, je préfère avoir 100% de la logique métier au niveau de l'application qui en a besoin. D'autant que c'est plus facile de faire des tests unitaires là que dans la base :)

Par contre pour ce qui est de faire de grosses opérations sur plein d'enregistrements, là les sprocs ont à nouveau tendance à être bien utiles (et plus performantes). Tant que ça se limite aux opérations, et que la logique au-dessus est... au-dessus :)

Pour répondre à la question du débat, je ne suis pas spécialement un fanatique des procédures (bien que je sois contre les datasets), mais je suis bien obligé de constater que l'élément primordial dans bon nombre de projets reste la base de données (projets bancaires notamment), et partant de là, les procédures stockées restent le meilleur compromis.

Il y a pas mal d'éléments à prendre en compte à chaque fois de toute façon. Pour un projet donné, tout faire passer par des sprocs peut être le mieux (voire obligatoire), pour un autre on peut les éviter complètement, pour encore un autre, on peut faire un petit mix. L'appli fait le gros du boulot mais on passe par des sprocs pour les parties qui en profitent vraiment.

C'est au cas par cas. Les sprocs sont un outil parmis tant d'autres, il faut de toute façon l'avoir dans son attirail.

Pour ce qui est des DataSets par contre... on va dire que ça permet de monter un truc rapidement (y compris via des sprocs), mais pour peu qu'on ait le temps de se pencher sur des alternatives, GO GO GO.

[Keihilin]

...des fois c'est carrément négatif.

...ça fait quand même 2 endroits où aller chercher les infos quand on veut savoir comment un truc fonctionne (et/ou le modifier), 2 endroits à tenir synchros quand les comportements sont liés, etc.

...je préfère avoir 100% de la logique métier au niveau de l'application qui en a besoin. D'autant que c'est plus facile de faire des tests unitaires là que dans la base

Le seul point négatif que l'on peut avancer est l'éparpillement de la logique métier...
Je pense que, toi comme moi, nous aimerions idéalement pouvoir toujours poser toute la logique dans l'application pour toutes les raisons que tu as données : conception, tests, etc...

Cela dit, en partant de mes expériences personnelles (certes liées à des types de projets particuliers mais majoritaires dans mon pays car les banques sont les plus gros consommateurs de développeurs), la base de données est dans 95% des cas l'élément le plus important du projet. Partant de là, mettre 100% de la logique métier dedans se justifie aisément. A coup de jolis termes à la mode comme "SOA", on décrit la BDD comme un service particulier, et l'accès à ce service, c'est les procédures stockées. Crois-moi, avec une bonne conception, des vues servant de façades et des procédures bien spécialisées, on peut arriver à suffisement "d'abstraction" pour rendre l'immense majorité des modifications de la base transparentes pour le client. C'est la souplesse du partage de schéma par rapport au partage de classes...

Malheureusement, les projets sont souvent pilotés par des architectes férus de POO qui vont saisir la moindre occasion de déplacer une partie de la logique dans l'application, et c'est comme ça que l'on se retrouve avec un éparpillement. C'est d'autant plus dommage que dans ces scénarii, l'application devrait se contenter de l'affichage, de la saisie et du reporting, point barre.

Mon cher Maniak, nous avons visiblement des expériences sur des types de projets différents, et j'aimerais bien que tu me donnes des exemples (en informatique de gestion) de situations ou mettre la logique métier dans l'application se justifiait par rapport à la base de données. Crois bien que je ne doute pas du bien fondé de tes analyses; j'espère juste enrichir ma culture en ayant des descriptions d'autres projets que les miens.

[CUCARACHA]

Salut,

Je me permets d'intervenir à nouveau pour répondre à Keihilin au sujet des exemples d'applications.

En fait, je pense que l'option couche de persistance, c'est à dire déplacement de la logique métier dans l'application, ne dépend pas de l'orientation fonctionnelle du projet mais de sa taille.

Prenons Peoplesoft par exemple. J'ai analysé le produit à l'époque où il tournait entièrement sur Oracle 8 et 9. Je ne sais pas si ça a évolué depuis mais à cette époque (2004) il n'y avait aucune relation d'intégrité référentielle entre les tables. Je précise que le module de base compte environ 35000 tables.

Dans un tel contexte, tu imagines bien qu'il n'y a pas qu'un sel développeur oracle dans l'équipe. Le projet est morcelé et pris en charge par plusieurs équipes. Si des relations d'intégrité référentielles existaient dans une telle base, il faudrait faire de très lourdes analyses d'impact avant de faire la moindre modification.

L'avantage de la couche de persistance est qu'elle permet de gérer l'intégrité référentielle entre les différentes entités sans que la base de données ne puisse se verrouiller et se bloquer.

Pour les projets de taille humaine, c'est à dire jusqu'à 200 tables et 1000 procédures stockées, un seul voir deux développeurs base de données suffisent. Dans ce cas, l'implémentation de la logique métier dans la base est justifié.

En conclusion je dirais :

Lorsque le projet compte moins de 200 tables, c'est la préférence du développeur ou du chef de projet qui sera appliquée. Au delà, je pense qu'il est indispensable d'extraire la logique métier de la base afin de disposer des outils de CAO type UML pour concevoir et intervenir sur la structure de données.

Êtes-vous d'accord avec ma conclusion ?

++

Laurent

[Keihilin]

En fait, je pense que l'option couche de persistance, c'est à dire déplacement de la logique métier dans l'application

Là je pense qu'on mélange les concepts...

Êtes-vous d'accord avec ma conclusion ?

Hélas non...

A mon avis, le débat sur l'emplacement de la logique métier ne dépend pas de la taille du projet, en tout cas, l'exemple de PeopleSoft n'est pas un argument...
Pour pondre 35'000 tables sans intégrité reférentielle, il faut avoir de solides raisons ou de sérieuses lacunes...Quoi qu'il en soit, si tu tiens ne serait-ce qu'un tout petit peu à tes données, tu vas devoir recréer des mécanismes de protection dans ton code client, et je crains que cette pratique de réinventer la roue n'ai pas grand chose à voir avec de la logique métier.

Que ton projet ai besoin de 10, 200 ou 30'000 tables ne change rien, la complexité de conception de la BDD va augmenter au fur et à mesure du nombre de tables, que la logique soit dans l'application cliente ou dans la base...
Les outils de CAO ne sont pas réservés à la POO, ils existent aussi pour les BDD.

[LefortLudovic]

Je ne comprend pas bien la question Dataset vs Procédures stockées ?

Rien ne vous empeche de remplir vos Dataset typé avec des procédures stockées ? Ce n'est pas l'un ou l'autre.

Q : Faut il utiliser les datasets ?
R: ça dépend
Je prend par exemple le cas d'une application windows form. Les datasets permettent à l'utilisateur de continuer à travailler même en cas de perte de connection avec la base de données.
Dans le cas d'une application web qui est toujours en mode connecté l'utilisation des datasets est déjà moins évidentes.

Q : Faut il utiliser DataSet + GridView + Detail View ?
R : ça dépend
Il est évident que l'utilisation de composant comme le GridView et le détail view fait perdre un peu de contrôle sur l'application.
Mais dans 90% des cas professionnels ce qui dirige un projet c'est le budget Utiliser les composants "tout fait" réduit énormément les délai et évite pas mal de bug ...

Je pense qu'il ne faut pas "cracher" sur les composants "clé en main" qui permettent de faire des choses relativement puissantes en très peu de temps.

Ludovic,

[CUCARACHA]

Salut

Concernant le mélange des concept, c'était pour simplifier. Ne pas confondre la logique métier dans la base de données et la couche métier en POO.

Concernant Peoplesoft, ça n'est qu'un constat de ce qui existe.

++

Laurent

[Maniak]

Le seul point négatif que l'on peut avancer est l'éparpillement de la logique métier...

Qui n'est pas forcément mineur, loin de là :)

Je pense que, toi comme moi, nous aimerions idéalement pouvoir toujours poser toute la logique dans l'application pour toutes les raisons que tu as données : conception, tests, etc...

Ah ça...

Malheureusement, les projets sont souvent pilotés par des architectes férus de POO qui vont saisir la moindre occasion de déplacer une partie de la logique dans l'application, et c'est comme ça que l'on se retrouve avec un éparpillement. C'est d'autant plus dommage que dans ces scénarii, l'application devrait se contenter de l'affichage, de la saisie et du reporting, point barre.

Si elle peut se limiter à ça et que le reste n'est que du traitement de données 'bête et méchant', pourquoi pas oui.

Mon cher Maniak, nous avons visiblement des expériences sur des types de projets différents, et j'aimerais bien que tu me donnes des exemples (en informatique de gestion) de situations ou mettre la logique métier dans l'application se justifiait par rapport à la base de données. Crois bien que je ne doute pas du bien fondé de tes analyses; j'espère juste enrichir ma culture en ayant des descriptions d'autres projets que les miens.

Info de gestion 'pure' je sais pas, mais je peux toujours prendre une partie de mon projet actuel comme exemple de cas où mettre tous les traitements dans la base n'est pas viable. Ça va être un peu long par contre :)

Il est découpé essentiellement en 3 projets : un site internet pour les visiteurs, un site backoffice et tout un processus d'import de données à partir d'un petit paquet de dizaines de clients qui balancent des fichiers dans des formats divers et variés, plus ou moins pourris (généralement plus).
Pour l'import des données, ça passe par pas mal de phases qui ont chacune pas mal de règles à appliquer. Là comme ça on pourrait se dire qu'on pourrait très bien tout caser du côté de la base, sauf que ce n'est pas si simple. En cours de route, il y a notamment besoin de prendre des images sur un serveur (via réseau local, http, ftp ou service web, selon l'alignement des astres), en générer de nouvelles et les stocker ailleurs. Il y a aussi besoin, après certaines règles, de faire des appels à Mappy, d'analyser le XML renvoyé et de mettre les données à jour derrière en repassant par d'autres règles, tout ça avant de pouvoir finaliser le traitement avec encore d'autres règles.

Autant dire que placer tout ça du côté de la base, quand une partie de la logique concerne des ressources sans rapport avec elle, c'est pas évident.

Sauf qu'actuellement, tout est fait du côté de la base, justement. Du SSIS pour gérer chaque flux, du VB.NET depuis SSIS pour retraiter les fichiers sources et des procédures stockées lancées (encore) depuis SSIS qui tournent à grands coups de curseurs pour traiter les données une à une, en faisant des appels à des librairies .NET pour tout ce qui est images & Mappy.

Super lourd à maintenir, super lourd à tester (rien d'automatique pour ça), les règles ont tendance à bouger assez facilement avec des cas particuliers qui se baladent par-ci par-là, il y a pas mal de lookups et vu que tout se fait enregistrement par enregistrement et qu'il n'y a pas vraiment de dictionnaire en SQL, ça refait pas mal de requêtes à chaque fois, le système de logging est quelque peu limité et peu pratique (en plus d'alourdir des sprocs déjà pas limpides), et des appels à .NET pour traiter des images et faire des requêtes HTTP... c'est ni performant ni stable (ni conseillé ni supporté par MS, on a vite compris pourquoi, mais le choix de tout ça avait été fait par ceux qui ont développé la chose au départ :)

En prime, on n'a pas accès au serveur SQL de prod, accès limité à celui de préprod et un serveur de dév trop faible pour y faire de vrais tests, il n'y a pas de DBA et la base a été faite par des boulets de première. Tu prends toutes les règles de design de bases et tu les jettes par la fenêtre, en passant par la structure des tables, l'organisation des index et les contraintes d'intégrité. Un exemple parmis tant d'autres, tous les identifiants sont des GUIDs, y compris pour des tables de référence contenant 3 lignes et utilisées un peu partout. Bref.

Au final, le système actuel, avec la quasi-totalité des règles gérées côté SQL, c'est un gros boxon. C'est pas beaucoup mieux du côté web cela dit, mais là y en a pour encore 10 pages de plus. En mentionnant au passage la *joie* de passer par des DataSets typés qui arrivent à regrouper 3 tables dans 1 classe, avec une moyenne de 100 colonnes par table, pour donner une idée :)

Pour la partie import des données donc, le process est en train d'être transformé petit à petit pour passer sur un service Windows et ramener l'ensemble des règles du côté .NET (et avec NHibernate en prime pour la persistence :)

He be y a pas à dire, c'est autrement plus pratique, testable (donc fiable), *carrément* plus performant (les dernières estimations font passer un traitement de 5 jours à 5 heures), plus maintenable, *carrément* mieux pour le versioning (surtout vu l'organisation du projet), il n'y a plus d'allers-retours entre SQL et .NET pour les traitements qui touchent des ressources externes, le système de logs est autrement plus simple (merci log4net pour permettre notamment de logger simultanément en base et en fichier), la gestion des transactions et des erreurs en cours de route est aussi à la fois simplifiée et plus solide, bref que du bonheur. Enfin presque, tout n'est pas rose non plus :)

Forcément s'il y a des changements dans les règles, il faut redéployer l'appli, alors qu'avec des sprocs ça peut se faire de façon transparente (si les changements ne sont pas trop violents). Dans ce cas-là, c'est un inconvénient mineur, le déploiement se fait très facilement. Un seul endroit où déployer, l'installation arrête proprement le service et la nouvelle version prend la suite là où il en était resté. Pas d'effet néfaste, c'est une question de secondes.

Il y aurait moyen de faire une version hybride en laissant une partie de la logique côté SQL (c'est d'ailleurs ce qui est fait pour le moment le temps de faire la transition, qui va s'étaler sur longtemps), mais l'objectif est justement de ne pas l'éparpiller. Donc vu que tout mettre côté SQL n'est clairement pas le top, l'alternative suivante est de tout mettre côté application. Sauf cas particuliers donc, qui gagneraient vraiment trop à rester côté SQL :)


Ah et donc pour refaire un lien avec le topic, le service en question passe actuellement par quelques sprocs histoire de réutiliser l'existant le temps de pouvoir repasser dessus (parce qu'on ne peut pas se permettre de tout arrêter le temps de tout refaire), mais elles sont en voie de disparition. Et aucun DataSet à l'horizon, évidemment.