Discussion :

[steph44470]

Bonjour, je recherche à faire un insert dans une table qui a les données en horizontal à partir d'une table qui a elle les données en vertical.
Je m'explique :
Table origine :
Champ 1 => le mois
Champ 2 => l'objectif
Champ 3 => le réalisé
Champ 4 => l'individu

Table résultante :
Champ 1 => l'individu
Champ 2 => objectif_mois_1
Champ 3 => realise_mois_1
Champ 4 => objectif_mois_2
Champ 5 => realise_mois_2
Champ 6 => objectif_mois_3
Champ 7 => realise_mois_3
...

Merci pour votre aide
Stéphane

[escartefigue]

Bonjour,

Quelle est la raison pour laquelle vous voulez constituer physiquement cette table ?
Si le besoin ne concerne que la restitution sous cette forme, une requête est nettement préférable à cette table qui non seulement constitue une redondance d'information (avec tous les risques que ça comporte) mais en plus déroge aux règles élémentaires de modélisation.

Questions subsidiaires
- combien y a -t-il de mois à documenter
- est-ce que tous les individus ont le même nombre de mois renseignés (en d'autres termes, pas de "null" dans le résultat)
- le résultat est il "one shot" ou sur un horizon glissant à rafraîchir tous les mois

[steph44470]

Bonjour,
il s'agit de la reprise d'une application qui maintenant met énormément de temps à se traiter.
Je ne peux pas tout modifier.

[escartefigue]

Si vous créez la nouvelle table que vous proposez, vous devrez de toutes façon écrire une requête pour en restituer le contenu, donc je maintiens que sauf besoin particulier, il est préférable de faire une requête sur la table existante, quitte à stocker cette requête dans une vue le cas échéant.

Quel est le contexte : beaucoup d'accès concurrents sur la table existante ? quel est le volume (nombre de lignes) de cette table ? quelles sont les requêtes qui mettent beaucoup de temps sur cette table ? sont elles sargables? avez vous fait des explain sur ces requêtes ? la table est elle partitionnée, selon quels critères, quels sont les verrous et l'isolation utilisés dans les requêtes d'accès à cette table...
Beaucoup de choses à vérifier, dupliquer les données est rarement la bonne solution.

[steph44470]

La table résultante fait 1 600 000 lignes et sert à faire des calculs sur des objectifs.
Actuellement, on procède comme suit :
Import des données dans une table temporaire via un fichier csv ( environ 3 000 000 )
Puis on récupère certaines données de l'application ( type individu actif ou non, homme ou femme, etc..)
Puis on fait un replace dans la table résultante avec les données du 1er mois et ensuite une boucle avec les données des mois suivants.
C'est cette boucle qui contient 3 inner join qui est très longue, 30 à 45 min

[escartefigue]

Je n'aurai pas le temps de m'y pencher de suite, mais sur le principe
- si par "boucle" il faut comprendre lecture d'un curseur, alors ce n'est pas optimisé : il est préférable de traiter les données de façon ensembliste dans la mesure du possible plutôt que ligne à ligne à travers un curseur
- les jointures ne pénalisent pas le traitement si les prédicats sont sargables

Communiquez la description exacte des tables et index et la requête complète pour une analyse plus pertinente

[steph44470]

Effectivement, on teste une insertion via un seul traitement.
Et tous nos critères sont sur des index.

Je te tiens au courant.

[escartefigue]

question subsidiaire : chaque individu a-t-il un et un seul objectif par mois ?