J'ai une GROSSE table (6oo.ooo enregristrments) dans laquelle je doit comparez tous les enregistrements les uns aux autres.
 
Bref, ca fait beaucoup de taf pour le serveur ...
 
Un ingénieur info de la boite m'a dit que sous oracle, il existait des programmes qui analysait les requetes, et qui proposait des améliorations.
 
Or, là, 1-2% d'amélioration, ca va se compter en heures...
Existe il la même chose pour MySQL (ou pour perl, j'écrit mon truc en perl), ou même un site qui serait spécialié la dedans
 
J'ai fait une recherche sur le forum et dans les site classique de sql (et y'en a), mais j'ai rien trouvé de transcandant la dessus ...
 
 
 
 

ca veut dire quoi comparer les uns aux autres?

[edtdd]--Message édité par jupiler--[/edtdd]

Y'a 6oo.ooo concepts dans un dictionnaire médicale (UMLS).
 
Je prend le concept C0001 et je regarde un de ses attribut (ici, son type semantique T022 par exemple).
 
Apres, je prend le concept C002 et je regarde son Typse semantique. Je compare avec le T022 de C00001.
Je passe au trois, et je recommence..... jusqu'au 6oo.oooème.
 
 
Une fois fini avec le 1, je passe a C0002, que je compare a C0003... et ainsi de suite jusqu'a C6oo.ooo
 
 
Et on continue gaiement jusqu'au dernier, le C6oo.ooo qui n'a plus personne à comparer ...
 
 
 
Bref, du gros boulôt pour le serveur en perspective.
Et le tout a ranger dans une table, evidament, sinon, c'est pas drôle.
D'ailleurs, y'a une limite à MySQL, si ce n'est la place sur le dur ??

c'est bien beau mais la comparaison doit retourner quoi?
 
au final tu dois stocker quoi?

La compraison fournit une relation possible entre les types sémantiques des deux concepts.
 
Chaque concepts a un ou plusieurs types semantiques. Les types semantiques sont parfois reliés entre eux.
 
Donc, ej prend un concept, son type semantique, et je regarde si il y a une relation entre son type semantique et celui du concept suivant.
Si il y a une relation, je met dans une table :  
Le premier concept, son TS (Type semantique) , le deuxieme concept, son TS et enfin, la relation liant les deux TS.
 
Puis, toujours avec le premier concept, je compare son TS avec le troisième concept.... et je continue.
 
 
En fait, j'ai deja ecrit un truc en perl qui fait le boulôt.
Sauf que ca prend des heures, ne serait ce que pour le premier concept. donc, je cherche des sites que je pourrait potasser pour améliorer ou me donner des idées sur la mainère d'améliorer les requetes

AAAAAAAARRrgghhhh, y'a pas de view sur MySQL .... avant la version 4.1
 
bon, je sens que je vais prendre une autre base

t'aurais pas plutôt intêret à modifier la structure de tes données ?

C'est à dire ??
aranger mes bases différament ??
 
de toutes facons, je sais que la base resultante sera énorme, ca je peux pas y couper.
Elle fera plusieurs millions d'enregitrements, ca, c'est sur.
J'ai fait des 'tits test, j'en suis a 61 Millions d'enregistrements pour 1 giga2 de données.
 
Y'aura peut être dix fois ca.
Donc, ca n'est pas trop le probleme, tant que Mysql suit, tout baigne. c'est plus au niveau du temps que je voudrait améliorer le truc.
La requete, je ne la lancerai qu'une fois, mais bon, si ca doit lui prendre un mois, c'est pas top non plus

[edtdd]--Message édité par TetardKing--[/edtdd]

600 000 entrées dans la table de départ, ca fait potentiellemnt 180 milliards d'enregistrement. pas sur que MySql puisse suivre
 
( 1 + 2 + 3 ...... + 599999 + 600000)

oui, je sais, j'ai fait le calcul
 
Mais a vu de nez, y'en aura pas plus de 7oo / 8oo millions
 
La base est énorme, normal que les requetes le soient.. mais j'ai pas le choix ...
 
Que ca marche ou pas, je m'en fout (enfin, je prefererais que ca marche), mais je bosse pour une fac, mais c'est le temps que ca va mettre pour tout calculer qui me desepère.
 
Sinon, je le fait tourner pendant les fêtes de noël
 
Donc, personne n'a ca sous le bras, un 'tit programme ou site qui permettrait d'ameliorer mes requetes ??

salut
si ce genre de requêtes est exceptionnel, tu peux essayer de bricoler, mais apparemment c'est pas possible...
méta-réponse : ton pb est un pb de conception Ta base est pas conçue pour traiter de telles requêtes... ...et tu exprimes ta req de manière procédurale & non ensembliste. Une seule solution : restructurer... bon courage !
ta table de concepts doit pouvoir être modélisée + finement.

TetardKing a écrit a écrit : oui, je sais, j'ai fait le calcul   Mais a vu de nez, y'en aura pas plus de 7oo / 8oo millions   La base est énorme, normal que les requetes le soient.. mais j'ai pas le choix ...   Que ca marche ou pas, je m'en fout (enfin, je prefererais que ca marche), mais je bosse pour une fac, mais c'est le temps que ca va mettre pour tout calculer qui me desepère.   Sinon, je le fait tourner pendant les fêtes de noël   Donc, personne n'a ca sous le bras, un 'tit programme ou site qui permettrait d'ameliorer mes requetes ??

 
ce ne sont pas les requetes qui seront énormes, mais la taille des données à mettre en mémoire ou en swap certainement.

Les bases sont ainsi faîtes :  
 
TABCUI :
 
cui                       TS   Def_TS
C0000005   T116   Amino Acid, Peptide, or Protein  
C0000005   T121   Pharmacologic Substance  
C0000005   T130   Indicator, Reagent, or Diagnostic Aid  
C0000039   T119   Lipid  
C0000039   T121   Pharmacologic Substance  
C0000052   T116   Amino Acid, Peptide, or Protein  
C0000052   T126   Enzyme  
 
Et la table de relation entre les TS :
TS   REL_entre TS   TS
 
T001   T186   T072  
T001   T186   T071  
T001   T142   T001  
T001   T142   T002  
T001   T142   T003  
T001   T142   T004  
T001   T142   T005  
T001   T142   T006  
 
 
Y'a que ca d'interessant.
Pas trop le choix de faire autrement, si ???

[edtdd]--Message édité par TetardKing--[/edtdd]

 
Tu as bien des index dans toutes les colonnes sur lesquelles tu fait des restrictions ???
ça joue pas mal

Tes tables sont correctement indexées ?
 
Tiens en passant c'est une base utilisée pour faire de la modélisation moléculaire ? Parce que ce dont tu parles ça me rappelle de vieux souvenirs de pharma, où un prof nous avait parlé des différents softs utilisés par l'industrie pharmaceutique pour modéliser (et tester) à moindre frais de nouvelles molécules.

krolours > Arrgh, grilled !

irulan> je suis en pharma aussi, mais dans un labo de medecine. La base UMLS est un GROS dictionnaire qui comporte des concepts. Ca sert ici pour faire un moteur d'indexation de documents médicaux, en indexant non pas sur les mots mais sur lse concepts.
 
ainsi, hepatho, hépatique, foie, sont indéxés de la meme manière, et c'est pratique
 
Sinon, pour les indexes, ou les metteriez vous exactement ?? si j'en met partout, je vais gonfler encore plus mes bases... m'enfin, ca en gonflera que les tables d'origines pas ma table finale... vous me conseilez d'en mettre partout ??

Non uniquement sur les colonnes utilisés par les jointures.

 
ca va surtout rallonger le temps de mise à jour des tables.
pense à mettre à jour les stats quand tu as rajouté les indexes

En fait le principe d'un index est le suivant : imagines que tu dois retrouver le N° de Téléphone de quelqu'un dans un carnet, en cherchant son nom.
Si tes numéros sont inscrits l'un à la suite de l'autre, tu mettras beaucoup de temps à retrouver le bon nom (des fois il sera au début, des fois à la fin, enfin on parle d'un point de vue statistique).
En revanche si tu a s un répertoire alphabétique, tu mettras beaucoup moins de temps à retrouver le nom que tu cherches.
 
En gros sans index tu demandes à ton moteur de BDD à chaque ligne d'aller lire quasiment la moitié de la table de 600000 enregistrements pour retrouver la ligne en relation. Donc pas étonnant que ce soit long !

[edtdd]--Message édité par irulan--[/edtdd]

mon programme perl prendle premier CUI (ici C0005) et son premier type semantique T116.
 
puis, le deuxième C00039 et son premier type semantique (T119).
 
Il regarde si il y a une relation entre T116 et T119. si il y en a une, il met le tout dans une table.
Si il n'y en a pas, il passe au deuxième TS  de C00039 = T121, et regarde a nouveau si il y a une relation entre TS1 (T116) et TS2 (T121).
Puis, pareil avec C000052...
 
Qd il a fini avec le premier TS, il passe à la deuxième ligne C0005 T121, et il continue ....
 
 
ARRRRRRGGGhhh, le pauvre P4, il va souffrir...
 
Rappel :  
 
TABCUI :
 
cui                       TS   Def_TS
C0000005   T116   Amino Acid, Peptide, or Protein  
C0000005   T121   Pharmacologic Substance  
C0000005   T130   Indicator, Reagent, or Diagnostic Aid  
C0000039   T119   Lipid  
C0000039   T121   Pharmacologic Substance  
C0000052   T116   Amino Acid, Peptide, or Protein  
C0000052   T126   Enzyme  
 
Et la table de relation entre les TS :
TS   REL_entre TS   TS
 
T001   T186   T072  
T001   T186   T071  
T001   T142   T001  
T001   T142   T002

[edtdd]--Message édité par TetardKing--[/edtdd]

Pourquoi tu n'utilises pas le SQL pour avoir directement les bonnes lignes ? En fait tu n'utilises pas du tout la puissance du moteur de la BDD !!
Tu peux faire un truc du genre :
 
Insert into Table_bidule (col1,col2,col3)
select col1,col2,col3 from Table_CUI, table_relation
where il existe une relation;
 
Et là tu obtiens directement toutes les lignes qui correspondent à tes besoins !!
N'utilises surtout pas un langage procédural, tu m'étonnes que tu vas mettre à genoux ta bécane

Sauf que la la clause where, elle fait trois pages.... et que je suis un total newbee en la matière... je connaissais pas SQL y'a deux jours
 
Et perl encore moins.
 
Par contre, si je ne m'abuse, les deux (perl et sql) tournent en C derrière, donc, la difference doit pas être si énorme, nan

Oh que si que c'est énorme la différence !!
Dans un cas tu utilises un script qui lit les lignes une par une, alors que dans l'autre tu utilises un système dédié au traitement de masse des données, et qui tourne sur un serveur en plus !

Table de relation entre les TS :
TS1   REL_entre TS   TS2
 
T001   T186   T072  
T001   T186   T071  
T001   T142   T001  
T001   T142   T002  
 
Tiens j'ai un peu réfléchi à ton truc, tu devrais creuser dans ce style  de requête :
 
Insert into TABLE_CIBLE
SELECT T1.CUI,T1.DEF_TS, TR.REL_ENTRE_TS, T2.CUI,T2.DEF_TS
FROM TAB_CUI T1, TABCUI T2, TABLE_RELATION TR
WHERE T1.TS = TR.TS1
AND T2.TS = TR.TS2;
 
En plus pour tester tu peux rajouter :
AND T1.CUI = 'C0000005'
 
ça te permettras de tester ce que renvoie ce genre de requête pour un CUI donné, avant de lancer sur 600000 lignes...
 
Dans tous les cas il sera vraiment important de mettre un index sur la colonne TS de CUI et la colonne TS1 de la table TABLE_RELATION ...

[edtdd]--Message édité par irulan--[/edtdd]

 
Ok pour le debut, tu crée une deuxième table re-contenant les CUI et leur TS.
On a donc TABCUI1 et TABCUI2 ainsi que TAB_REL
 
Je reflechi au tout
Deux secondes

Et arrete d'éditer ton message

Non tu ne recrées PAS une 2ème table, tu utilises la même mais avec 2 alias différents.
 
Bienvenue dans le monde merveilleux des bases de données

TetardKing a écrit a écrit : Et arrete d'éditer ton message

 
Bon Ok, c'était pour voir si tu suivais

Et TABCUI2, il va la créer tout seul comme un grand
trop fort sql ...

FROM TABCUI T1, TABCUI T2, TABLE_RELATION TR
 
C'est les T1 et T2 de ton from .... ok ok, j'ai compris, il fait une table T1 et T2  "virtuelle" a partir de TABCUI...

Relis attentivement    
 
... TAB_CUI T1, TABCUI T2,...
 
Où vois-tu TABCUI2 ??
T1 et T2 sont les alias de TABCUI

[edtdd]--Message édité par irulan--[/edtdd]

Ca vient, ça vient Fais gaffe tu vas finir par aimer ça

TAB_CUI T1, TABCUI T2,...
 
oui uoi, j'ai compris depuis.
Mais pourquoi tu met une fois TAB_CUI et une autre fois TABCUI

irulan a écrit a écrit : Ca vient, ça vient Fais gaffe tu vas finir par aimer ça

J'aime déjà ca, pharma, c'est une erreure d'orientation

C'est pour l'utiliser à la fois sur TS1 et sur TS2 de la table TABLE_RELATION

TetardKing a écrit a écrit :   J'aime déjà ca, pharma, c'est une erreure d'orientation

 
Oui, ça arrive j'ai fait la même

Bon, je vais essayer de faire bouiner ton truc, on va bien voir ce qu'il me dit
Je te fait signe pour te donner l'avancement
 
Merci beaucoup en tout cas :jap:

Ok, J'espère que ça t'aideras...
 
Sinon là je pars du taf, mais bon n'hésite pas à reposter voire à me mailer (cf profil) si tu as besoin.
 
 

et bon WE