Discussion :

[Tgaud]

Bonjour, nous faisons actuellement une procédure stockée sous sybase,
qui retourne une multitude de lignes colonnes pour un rapport.

le traitement dure entre 30mn et 1h il est assez lourd, et est constituée de plusieurs phases :

_Generation du "tronc" d'insert dans un table de travail

_enrichissement des colonnes supplémentaires à partir d'une multitude de tables en jointures pour le select final.


Donc en gros :
_Quelques phases d'insert successives des lignes de bases :
_quelques phases d'updates successives sur des colonnes suplémentaires
_un gros select final qui ramene les données

Cette procédure est un gros select en somme.


tout se passe dans une procédure stockée, mais on voulais savoir si on pourrait gagner en performances, en transferant une partie du traitement à LINQ. (et si oui quel linq ?)

Peut il rivaliser avec le moteur SQL sous pretexte qu'il travaille en mémoire ? ou il y a t'il une manière précise de l'utiliser ?
ou estce que cest juste un outil de conception, qui ne maidera pas pour les perfs face à une proc stock ?

[simodox]

Bonjour,
En réponse a ta question je dirais que les procédures stockées sont plus performant que le linq. aprés, il y'a toujours moyen d'optimiser le temps de traitement (expl: utiliser JOINT au lieu d'une jointure standard A.id=B.id)

Donne le max d'infos, comme ça on pourra t'aider

[Tgaud]

Bonjour,

JOINT ? d'autres infos la dessus ?
Sinon quels sont les avantages de linq question performance ?
les cas ou il se distingue ?

10 phases d'insert successives,
puis
33 phases d'updates successives sur des colonnes supl,

sinon mon select final :
14 tables en jointure(2 interne le reste externe), 140colonnes ramenées
pour un total de 64 000 lignes en sortie.

[oyigit]

Le principal avantage de linq est qu'il permet de manipuler une base de données assez rapidement. En fait, tu peux gagner beaucoup de temps si tu développe une couche d'accès aux données. En revanche, pour des processus complexe, rien ne vaut une procédure stocké. D'ailleurs tu peux accéder à des procédures stockées avec linq, et même des vues pour des requêtes complexes. Dans ton cas, au mieux tu pourra optimiser ta procédure stockée. A moins que tu traites énormement de données, une requête qui dure de 1h me paraît bizarre.

[Tgaud]

Et le fait que linq travaille en mémoire, n'apporte aucune bénéfice en comparaison ? que ce soit linq to sql, linq to entities ou autre ?

On me dit dans mon équipe que lorsque l'on doit faire du retraitement/manipulation de données etc, cest plus rapide en memoire.

[simodox]

Ce que je voulais dire c'est qu'il est fréquent qu'une requête mal écrite coûte 10 fois plus de temps et de ressources qu'elle ne le devrait.
genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT *
FROM   T_CLIENT C, T_FACTURE F
WHERE  EXTRACT(YEAR FROM F.FAC_DATE) = 2000
  AND  F.CLI_ID = C.CLI_ID

mieux faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT *
FROM   T_CLIENT C
       JOIN T_FACTURE F
            ON F.CLI_ID = C.CLI_ID 
WHERE  EXTRACT(YEAR FROM F.FAC_DATE) = 2000

ET non, pour moi, linq ne va apporter aucun avantage pour ton cas.

[simodox]

Les plus de LINQ
* Les développeurs n'écriront plus de SELECT * et passerons systématiquement la liste des champs au moteur, de ce point de vue certains cas d'optimisation côté SQL seront mieux traités
* Les noms d'objets sont totalement qualifié : « schéma.objet » sans que le développeur ai à s'en préoccupé, là aussi c'est un plus important pour des questions de performance et de sécurité.
* Le format de la requête SQL est géré par LINQ, ainsi que contenu, double avantage permettant de limiter très fortement les risques d'injection SQL et de permettre de meilleures réutilisations de plans basé sur le texte de la requête.
* Certaines requêtes (de type « renvoie-moi les 20 enregistrements après le 2500 par rapport à tel critères ») sont très simplifiées vue du développeur et ne nécessitent pas de connaissances approfondies du code SQL.
* C'est une bonne couche d'abstraction de code SQL, cela améliore pas mal l'interopérabilité entre les moteur de base de données. A condition toute fois que les éditeurs d'autres moteurs jouent le jeu.

Les moins de LINQ

* Le code SQL/LINQ est géré côté application ce qui oblige en cas de patch du schéma à revoir le code de l'application, idem en cas d'optimisation un peu poussé. Forcera-t-on le DBA à mettre le nez dans le code de l'application ?
* Là où certaines requêtes sont plus simples, d'autres au contraire deviennent vite très complexes, c'est le cas par exemple des jointures externe. Cela force le développeur à résonner à l'aide de sous requête et le code devient alors plus lourd qu'en SQL.
* Rajouter une couche d'abstraction revient à alourdir l'ensemble de l'accès aux données et à ralentir encore un peu plus l'ensemble. Pas de miracle ici, interopérabilité signifie généralement sacrifier un peu les performances.
* La gestion des transactions reste pour le moment un peu floue, est ce que le traitement est fait à 100% au niveau du moteur SQL ou un mix .Net / SQL. Rajouter une couche d'abstraction fait un peu perdre de vue cette notion et son contrôle.

[Tgaud]

Ce que je voulais dire c'est qu'il est fréquent qu'une requête mal écrite coûte 10 fois plus de temps et de ressources qu'elle ne le devrait.
genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT *
FROM   T_CLIENT C, T_FACTURE F
WHERE  EXTRACT(YEAR FROM F.FAC_DATE) = 2000
  AND  F.CLI_ID = C.CLI_ID

mieux faire:
SELECT *
FROM T_CLIENT C
JOIN T_FACTURE F
ON F.CLI_ID = C.CLI_ID
WHERE EXTRACT(YEAR FROM F.FAC_DATE) = 2000

ET non, pour moi, linq ne va apporter aucun avantage pour ton cas.

Tu es en train de dire que faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Select table1.toto from table1, table2
where table1.titi = table2.titi

est moins performant que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Select table1.toto from table1
inner join table2 on table1.titi = table2.titi

???

Car de ce que j'ai appris, ça reviens totalement au même d'un point de vue perf.

[Nathanael Marchand]

Il fut un temps, j'avais bossé à un batch d'intégration de données (essentiellement de la fusion et/ou ajout) qui prenait 40h en utilisant LINQ-to-SQL. On est passé a 4mn en faisant du bulk insert et merge directement en SQL.
Si tu veux travailler sur les entités en mémoire avec linq to objects, ca veut dire monter tous tes objets en mémoire et ca ne vaut pas le coup! Un SGBDR est concu pour être requeté. Il faut optimiser le SQL de la procédure plutôt.

[Nathanael Marchand]

Tu es en train de dire que faire :

Select table1.toto from table1, table2
where table1.titi = table2.titi

est moins performant que

Select table1.toto from table1
inner join table2 on table1.titi = table2.titi


???

Car de ce que j'ai appris, ça reviens totalement au même d'un point de vue perf.

Demande les plans d'executions sur la requete à SQL Management Studio et tu auras ta réponse(mais il me semble que c'est la même chose).

[Tgaud]

Je suis sur sybase.

[simodox]

Non ça reviens pas totalement au même
Tu trouvera ton bonheur et plus d'explication ici: http://sqlpro.developpez.com/cours/optimiser/

Bon courage

[Tgaud]

?? il n'est indiqué nul part que ça fait gagner en perf.

c'est juste des bonnes habitudes à mettre en place sans en préciser la raison.

Pour cet exemple précis je pense que l'idée est la lisibilité, pas les perfs.

as tu une source précise ? car tout ce que je trouve sur le net tend à dire que ça reviens au même d'un point de vue perf.

[simodox]

Je ne sais pas s'il y'a une source précise et fiable sur internet, mais j'ai apris ca lors d'une conférence. Bref, t'a qu'a tester et nous dire

Si non, le but de document, ci dessus, est l'OPTIMISATION des SGBDR et du SQL. à la fin de chaque section il y'a un petit paragraphe "CE QUI FAIT GAGNER DU TEMPS..."

peut etre tu pourrais commencer(si ce n'est pas encore fait), de supprimer certaines parties de ta requete, voir s'il y a un endroit ou il perd beaucoup plus de temps qu'a d'autres ....

Bon courage

[cinemania]

bon vu que ce post n'est pas marqué comme résolu, j'apporte ma pierre à l'édifice...

j'ai déja connu le meme souci chez un client.

Ta procédure stockée fait un traitement SQL pour SQL, je m'entend les traitements que tu fait vont de SQL vers SQL, il ne faut donc en AUCUN CAS sortir du SGBDR pour mettre une partie du traitement à l'extérieur... en effet, tu n'a pas besoin d'un programme tiers pour venir faire ce que ton SGBDR sais mieux faire que quiconque.
Si ta proc stock servait à retourner des tas de resultset ou un resultset énorme je dit pas qu'"il ne vaudrait mieux pas la décomposer directement dans ton appli, mais là non.

Un traitement de type bulk/batch interne comme par exemple du datamining dans un datawarehouse pour générer des data marts en vue d'un reporting future n'a rien à foutre dans une appli tiers...
au mieux tu pourra faire appel a une appli tiers pour faire de l'intégration de données, et en phase finale pour afficher le résultat, mais pas entre les 2.

Rien ne te fera gagner du temps à part réécrire tes procédures stockées de façon a être mieux optimisées.
Il faut savoir que Sybase et SQL Server sont les deux seuls SGBDR du marché à ré-agencer les requêtes select en algèbre relationnelles avant de les reconstruire et de les exécuter, pour faire de l'optimisation. Malgré cela, ce ne sont pas des être humains, il leur est donc impossible de ce mettre dans ta tête pour savoir ce que tu veux au final et certaines optimisations leur sont donc impossible sauf si tu les guide un peu. Sybase comme SQL Server peuvent t'afficher leur plan d'exécution, il t'es donc possible de remanier certaines requêtes pour voir si tu ne peut pas modifier ce plan de façon à faire gagner un temps précieux.

Pour ce qui est d'utiliser des jointures explicites de type JOIN plutôt que des jointures naturelles... la rapidité n'est viable que sous SQL Server qui a été optimisé spécialement en ce sens par Microsoft, mais jusqu'ici, et particulièrement sous Sybase il a tjs été conseillé d'avoir recours aux jointures naturelles que l'optimisateur peut alors ré-agencer pour améliorer le rendement, et qui seront probablement plus rapide que les jointures explicites et quelques soit leur nature.
Microsoft a porté une attention particulière sur les jointures pour SQL Server 2005 de façon à les optimiser au mieux si tu utilise des inner join, ce qu'il a tendance lui même à faire automatiquement quand tu regarde un plan d'exécution d'une jointure naturelle, malheureusement, je ne me souviens avoir lu nul part que Sybase œuvrait de concert ou du moins abondait dans le même sens...

Sachant tout cela il faut que tu essaie au cas par cas, mais il est vrai que même si parfois des jointures naturelles peuvent avoir de meilleur résultats sous Sybase, faire une jointure naturelle de 15 tables énormes n'est JAMAIS une bonne idée... trop de données à traiter simultanément sans filtrage et recoupements en amont, ni rien... c'est un cauchemar à compiler et exécuter.

voilà j'espère avoir répondu à ta question.