[Prog. en général] Question fondamentale sur le parcours d'un doc

Question fondamentale sur le parcours d'un doc [Prog. en général] - C#/.NET managed - Programmation

Marsh Posté le 13-11-2003 à 14:08:53    

Salut à tous
 
Ma question est assez générale et peut sans doute s'appliquer à tous les langages de prog.
 
Mon problème est le suivant. J'ai un document à parcourir. J'ai une base de données Access à laquelle j'accède par le biais de requêtes SQL. La BD constitue en fait un thésaurus, c'est-à-dire un dictionnaire de termes (mots ou expressions).
Je dois parcourir mon document et si dans ma BD se trouve le terme correspondant à mon itération actuelle, je dois le remplacer par sa traduction stockée dans la BD. Il est à noter que la taille des documents en question peut être relativement énorme (jusqu'à 10 000 lignes).
 
Mon but est de trouver le moyen le plus rapide d'effectuer cela.
 
Je pensais raisonner par ligne :
parcourir chaque élément de chaque ligne et à chaque fois effectuer une requête ds la BD pour voir si l'élément en cours s'y trouve. Mais sur un docement de 100 000 enregistrements, ça peut durer et c'est sûrement pas la manière la plus optimisée :/
 
De toutes manières, je pense que dans tous les cas, le traitement durera quelques plombes, mais tant qu'à faire, j'aimerai l'effectuer le + rapidement possible :)
 
Si vous avez des idées merci de m'en faire part  :hello:


---------------
Sans ma barbe, quelle barbe !
Reply

Marsh Posté le 13-11-2003 à 14:08:53   

Reply

Marsh Posté le 13-11-2003 à 19:16:37    

>> De toutes manières, je pense que dans tous les cas, le traitement durera quelques plombes
 
Je suis pas sûr de suivre, tu as un doc qui peut contenir jusqu'à 100 000 enregistrements, chacun devant être vérifié pour voir s'il existe dans la db ? Ça ferait 100 000 requêtes, ça devrait au plus prendre qq minutes ... Tu as déjà essayé ton parcours bourrin, avec un gros doc et une grosse db ? Quel temps ?

Reply

Marsh Posté le 14-11-2003 à 10:37:39    

youdontcare a écrit :

>> De toutes manières, je pense que dans tous les cas, le traitement durera quelques plombes
 
Je suis pas sûr de suivre, tu as un doc qui peut contenir jusqu'à 100 000 enregistrements, chacun devant être vérifié pour voir s'il existe dans la db ? Ça ferait 100 000 requêtes, ça devrait au plus prendre qq minutes ... Tu as déjà essayé ton parcours bourrin, avec un gros doc et une grosse db ? Quel temps ?


 
Alors je viens d'essayer. La db est quasiment vierge...
Le doc en question : 2828 lignes, 17598 mots.
 
Le traitement prend 13min26s (sur un PIV classique 2.4 et 768Mo de RAM)
 
Je rappelle comment j'ai procédé :
 
- j'analyse chaque ligne dans une boucle générale
- chaque mot de chaque ligne est comparé à la db par le biais d'un SELECT. Si le mot est trouvé, un autre SELECT est effectué pour déterminer la traduction du mot en question. Une petite boucle se charge de reconstituer la ligne ds le bon ordre avec les traductions incluses...
...et ainsi de suite


Message édité par Corbier le 14-11-2003 à 10:38:37

---------------
Sans ma barbe, quelle barbe !
Reply

Marsh Posté le 14-11-2003 à 10:46:21    

Tu peux ptet utiliser une hash table pour faire une première passe, et y ranger les mots et leur position. Ainsi regrouppés tu n'auras qu'un select à faire pour chaque entrée de ta table.
Tu peux aussi combiner les 2 select: SELECT motTraduit FROM TRADUCTION WHERE idMotTraduit = (SELECT idMot FROM MOTS WHERE mot = 'mon_mot')
Ce ne sont juste que des idées en vrac, à voir si ça vaut le coup ;)

Reply

Marsh Posté le 14-11-2003 à 10:50:21    

moktar1er a écrit :

Tu peux ptet utiliser une hash table pour faire une première passe, et y ranger les mots et leur position. Ainsi regrouppés tu n'auras qu'un select à faire pour chaque entrée de ta table.
Tu peux aussi combiner les 2 select: SELECT motTraduit FROM TRADUCTION WHERE idMotTraduit = (SELECT idMot FROM MOTS WHERE mot = 'mon_mot')
Ce ne sont juste que des idées en vrac, à voir si ça vaut le coup ;)


 
Merci pour ta réponse !
En fait, le 2eme Select est rarement utilisé, puisqu'il n'y a pas encore grand chose ds la DB (mais c'est une idée à prendre en compte lorsque la DB prendra de l'importance)...


---------------
Sans ma barbe, quelle barbe !
Reply

Marsh Posté le 14-11-2003 à 14:13:27    

deja... changer de système de base de données? jsuis pas certain que db access soit le plus rapide pour de gros truc
 
quelqu'un confirme?


---------------
http://www.boincstats.com/signature/user_664861.gif
Reply

Marsh Posté le 14-11-2003 à 14:17:09    

burgergold a écrit :

deja... changer de système de base de données? jsuis pas certain que db access soit le plus rapide pour de gros truc
 
quelqu'un confirme?


 
J'suis d'accord avec toi, Access n'est pas ce qu'il y a de plus rapide... Mais dans mon projet, je n'ai que ça sous la main et il n'est pas question de passer par du MySQL ou autres... les contraintes...  :sweat:


---------------
Sans ma barbe, quelle barbe !
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed