Choix / best practice sur methode utilisation SQL

**zax-tfh** · 19/10/2009, 23h02

Bonjour à tous,

Je cherche à trouver un compromis entre productivité et performances pour une application connectée à une base SQL.
Je dois avouer que j'en perd mon latin....
J'ai eu l'experience de créer une application dont les objets métiers avaient les requetes SQL codées à l'intérieur ou bien en procédures stockées et je trouve cela fastidieux.
Ensuite j'ai testé les datasets et je trouve ça hyper hyper pratique mais on m'a dit que niveau perfs ca devenait vite limité quand il y avait un grand nombre de résultats.

Que préconiseriez vous comme bonne solution pour l'utilisation d'une base SQL afin d'avoir de bons résultats avec un grand nombre de réponses, et ceci tout en essayant de garder un maximum de productivité (comme avec les datasets et leurs tableadapters).
Je sais que ma question est plutot vague mais je dois avouer ne plus savoir vers quoi me tourner dans mes recherches car chacun y va de sa méthode et je suis plus en recherche d'un best practice (ou au moins un comparatif de méthodes).

Merci d'avance

**Philippe Vialatte** · 19/10/2009, 23h43

Salut,

Je cherche à trouver un compromis entre productivité et performances pour une application connectée à une base SQL.

Ma réponse va forcément être à prendre avec un grain de sel, alors je vas te donner un peu de contexte...

J'ai commencé il y'à un petit moment à écrire des applis utilisant massivement des bases de données.

Quand j'ai commencé à faire sérieusement du .net, les datasets fortement typés sont passés à la trappe pour une raison toute bête, à savoir des difficultés de merge avec CVS

. Après, j'ai récupéré des softs codés avec des datasets fortement typés, pour une petite appli, ca marche, pour une grosse appli, ca devient vite impossible à maintenir et c'est, par rapport à d'autres méthodes, super lourd (designer graphique, lenteur des wizards, etc...)

A peu prés 80% des applis que j'ai développé utilisaient un modèle ou on passait par une requète sql ou une procédure stockée, mappée "manuellement" sur des objets POCO...ca marche bien, c'est raisonnablement performant, mais question productivité, c'est bof...le fait que la base de données ne soit pas liée fortement au code induit des bugs (fautes de frappe, etc), et le fait d'avoir, dans le cas des procédures stockées, de l'"intelligence" dans la base de données peut compliquer le deboguage.

La, je suis dans le camp des utilisateurs d'ORM (n'importe lequel

), en gardant à l'esprit qu'ils sont particulièrement adaptés pour des requêtes "normales", et qu'en général, ils permettent de taper sur des vues ou des procèdures stockées assez facilement quand il est nécessaire de faire plus de traitements coté SGBD.

Si tu as des problématiques plus précises en tête, détailles les un peu

**p_mehdi** · 20/10/2009, 07h49

C'est vrai que ta question est plutôt vague..

J'ai bossé sur pas mal de technos et dans pas mal de boîte... Et franchement les Best practices je suis pas sûr que ça existe vraiment..

Moi a mon avis tout dépend de la techno et du sgbd utilisé... Chacun a ses particularités....

Ensuite et surtour tout dépend de ce que tu veux développez... Je suis dans une boîte ou les architectes sont rois... Et pour un pauvre programme qui va traiter 3 enregistrements il faut monter une usine a gaz conceptuel...

Un conseil l'informatique c'est beaucoup de méthode mais surtout beaucoup de feeling...

**zax-tfh** · 20/10/2009, 10h28

Salut

Merci pour vos reponses

Alors ma question est assez vague simplement par méconnaissance du framework et de ce qui se fait en général en entreprise au niveau des bases de données.

Mon contexte a moi est très simple : j'ai déjà mené un projet assez complexe avec une trentaine de classes métier se connectant toutes à une base mysql distante. Le fait d'embarquer les requetes dans ces classes ne me plaisait pas vraiment pour trois raisons :
1 - La maintenant était super galère
2 - La portabilité niveau SGBD n'etait pas super
3 - La productivité n'etait pas géniale

Par contre l'avantage c'est que tout était là et que ça fonctionnait très bien.

Ma recherche se porte plutot sur le fait qu'il existe pas mal de méthodes qui font leurs preuves et je cherche a avoir des retours d'expériences permettant :
1 - de séparer la couche d'accès aux données du métier
2 - une grande productivité (les datasets m'ont séduit pour ça)
3 - une portabilité, le jour ou on demande le changement de SGBD ca doit pouvoir se faire simplement
4 - de bonnes perfs meme avec beaucoup de réponses.

@Philippe : penses tu que NHibernate est un bon choix meme pour de petits projets ?

Merci à vous

**Philippe Vialatte** · 20/10/2009, 17h12

Salut

Envoyé par zax-tfh

1 - de séparer la couche d'accès aux données du métier

Tu peux faire ca tres facilement, il suffit que tes classes metiers appellent des classes d'acces aux donnees situees dans un autre namespace

2 - une grande productivité (les datasets m'ont séduit pour ça)

J'ai oublie de te le mentionner, mais EF et Linq to Sql sont pas mal du tout dans le genre pour la productivite. subsonic ausi, NHibernate demande un peu plus d'apprentissage, mais une fois que tu maitrise, c'est assez souple

3 - une portabilité, le jour ou on demande le changement de SGBD ca doit pouvoir se faire simplement

Normalement, la plupart des ORM te permettent de switcher facilement la base de donnees derriere...sauf Linq To Sql

4 - de bonnes perfs meme avec beaucoup de réponses.

tout depends de ce que tu entends par beaucoup de reponses...si tu recuperes 1 000 000 d'enregistrement a chaque chargement de page, le bottleneck, ce ne sera pas lÓRM, mais ta base de donnees

@Philippe : penses tu que NHibernate est un bon choix meme pour de petits projets ?

Perso, NHibernate, pour moi, c'est principalement un choix si tu as un risque d'avoir une base de donnees tres differente de ton modele objet et/ou un benefice a utiliser le pattren unit of work...Si tu fais du mapping 1 table pour 1 classe, que tu as un modele assez simple et que ton appli est la pour fournir une interface plus ou moins sexy a la base de donnees, ce n'est un bon choix que si tu connais deja NHibernate

**zax-tfh** · 20/10/2009, 21h38

Merci Philippe pour ces indications

Je me penche actuellement sur NHibernate. Pas évident au premier abord, les tutos sont assez heterogenes et pas forcement a jour ^^ mais c'est tres interessant.