Optimisation de gestion de fichier - Algo - Programmation
Marsh Posté le 23-12-2003 à 15:35:10
Ouch
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.
Marsh Posté le 23-12-2003 à 15:51:26
viiz a écrit : "Ya pas de solution" n'est pas une solution |
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à
As-tu au moins testé une version avec un DB avant de la qualifier de trop lente ?
Marsh Posté le 23-12-2003 à 16:19:18
viiz a écrit : oui. Interbase. |
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.
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
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)
Marsh Posté le 23-12-2003 à 21:18:02
viiz a écrit : A savoir que j'utilise Delphi pour parser mon fichier. |
regarde les stream dans delphi
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
Marsh Posté le 28-12-2003 à 02:27:13
viiz a écrit : |
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 ?
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...
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 !)
Marsh Posté le 23-12-2003 à 15:27:43
Quelqu'un a une idée pour résoudre ca ?
Utilise une base de données !