Optimisation de gestion de fichier

Optimisation de gestion de fichier - Algo - Programmation

Marsh Posté le 23-12-2003 à 15:27:43    

viiz a écrit :

Quelqu'un a une idée pour résoudre ca ?

Utilise une base de données !  

Reply

Marsh Posté le 23-12-2003 à 15:27:43   

Reply

Marsh Posté le 23-12-2003 à 15:35:10    

Ouch :D
 
Avant peu tu va avoir des problèmes d'atomicité (Le programme allait effacer un utilisateur & tous ses messages, il a effacé l'utilisateur mais ... coupure de courant), de rapidité d'accès (plusieurs dizaines de milliers de messages), donc implémentation d'un btree ou autre, et puis hop, rajout d'un ènième message, mais nouvelle coupure de courant, tout ton fichier est corrompu ...
 
Bref, tu réinventes l'ACID. Il n'y a pas de solution miracle pour ton problème.

Reply

Marsh Posté le 23-12-2003 à 15:51:26    

viiz a écrit :

"Ya pas de solution" n'est pas une solution  :D

Je n'ai pas dit ça, j'ai dit pas de solution miracle. Tu vas réinventer la base de données, en plus lent, moins élégant et moins efficace que ce qui existe déjà [:spamafote]
 
As-tu au moins testé une version avec un DB avant de la qualifier de trop lente ?

Reply

Marsh Posté le 23-12-2003 à 16:19:18    

viiz a écrit :

oui. Interbase.
Bcp trop lourd et pourtant c une des moins gourmandes en ressource. En plus appli critique, donc le moins d'appel externe possible.

Je ne connais pas Interbase. Ça m'étonne que ce soit lent pour qq dizaines de milliers de messages. Manque d'indices peut-être ?
 
Tu peux t'orienter vers qq chose comme http://www.jwz.org/doc/mailsum.html , mais je doute que ce soit plus efficace qu'une DB dans ton cas.

Reply

Marsh Posté le 23-12-2003 à 19:46:50    

clair que peut importe la solution que tu tenteras, ca risque d'être tjrs plus lent qu'une db

Reply

Marsh Posté le 23-12-2003 à 21:17:10    

Burgergold a écrit :

clair que peut importe la solution que tu tenteras, ca risque d'être tjrs plus lent qu'une db


 
pas vrai une bd c'est très souvent lent surtout pour faire des traitements...
 
si on a beaucoup de traitement à faire avec les données mieux vaut les extraires faire ce qu'on désire et les remettres dans la bd...
 
c'est ce que fait sprint (téléphonie)


---------------
Borland rulez: http://pages.infinit.net/borland
Reply

Marsh Posté le 23-12-2003 à 21:18:02    

viiz a écrit :

A savoir que j'utilise Delphi pour parser mon fichier.
Dans un fichier texte je dois gérér une liste de messages destinée à un ou plusieurs users.
Un message peut être destiné a plusieurs user  et un user peut recevoir plusieurs message.
Lorsqu'un user a récupéré un message lui étant destiné, je le supprime de la liste des destinataires pour le message en question. Lorsqu'un message n'a plus de destinataire, il
est supprimé du fichier.
Le probleme est que le fichier peu contenir plusieurs dizaines de millier de messages et des centaines d'utilisateurs.
 
Si je décide d'utiliser un fichier groupé par message...
 
Message1:
User1
User2
User3
User4
Message2:
User2
User3
Message4:
User1
 
...le parsing pour récuperer la liste des fichiers d'un utilisateur en particulier risque d'etre long...
 
et si je décide d'utiliser un fichier groupé par utilisateur...
User1:
Message1
Message2
Message3
User2:
Message1
User3:
Message2
 
... je ne pourrais pas savoir quand un fichier n'a plus de destinataires, a moins de tout reparcourir...
 
En gros aucune des 2 solutions n'est satisfaisante :-/
Quelqu'un a une idée pour résoudre ca ?
Avec 2 fichiers synchro peut-etre ?
 
Merci A+


 
regarde les stream dans delphi


---------------
Borland rulez: http://pages.infinit.net/borland
Reply

Marsh Posté le 27-12-2003 à 16:38:00    

Je capte pas trop le coup de "trop lent".
 
Y'a combien de millions de connections à la secondes à ton truc ? Parceque en dessous du million, je vois pas comment un select/update/insert/update peut être plus lent que bosser dans un fichier, surtout vu le type de fichier que tu utilises... C'est même pas un fichier à pas fixe ! Même Access est plus rapide :lol:

Reply

Marsh Posté le 28-12-2003 à 02:27:13    

viiz a écrit :


 
Ah j'ai oublié de préciser:
Pas de database, pas d'XML.
Trop lourd, et j'ai un gros besoin de perf.
Peu importe le niveau de complexité du moment que ca va vite et que ca n'est pas lourd.


Ben là...
 
Lourd... Dans quel sens si ce n'est les performances ?
 
Tu fait tourner ton truc sur un goupil avec 2 Ko de mémoire ou quoi ?

Reply

Marsh Posté le 28-12-2003 à 02:29:08    

Donc je me permet de demander : POURQUOI pas de BDD ?
Ca sert à ça, je vois pas pourquoi tu devrais pas l'utiliser. Et quand on voit ce que consomment les petits SGBD gratuit et largement assez performants pour ce que tu fais, je capte pas pourquoi tu en veut pas...

Reply

Marsh Posté le 28-12-2003 à 02:29:08   

Reply

Marsh Posté le 28-12-2003 à 03:40:17    

Un fichier *.mdb (Access) permet d'utiliser le moteur d'Access (c'est pas hyper génial, mais vu l'utilisation, je pense sincèrement que c'est amplement suffisant) sans rien installer.
 
Ca marchera d'entrée de jeu à condition que le fichier soit au format Access 2.0, sur tous les Windows à partir de 98/NT4.
 
Tu tapes dans la base via MSJET qui est intégré d'office à partir de ces versions, donc t'as pas besoin d'installer quoique ce soit en plus du soft : tu distribues l'exe accompagné de son fichier mdb et zou.
 
Sinon, après, tu peux toujours te faire chier à faire ça à la main, mais clairement, soit tu vas utiliser un truc hyper limité, qui va finir soit par bugger dans tous les sens, soit devenir super lent, tout en y ayant passé un temps monstrueux.
 
Donc clairement, je pense que le premier truc à faire, c'est convaincre ton DT de soit :
- utiliser une base Access (je rappelle, rigoureusement rien besoin d'installer à partir de Windows 98, Access lui-même n'est pas requis)
- t'authoriser à bosser avec un fichier XML (il faudra distribuer MSXML 3.0 sur les PC sous 98, NT4 et 2K, sâchant que c'est pas les mêmes versions !)


Message édité par MagicBuzz le 28-12-2003 à 03:40:37
Reply

Sujets relatifs:

Leave a Replay

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