<<si j'imagine un usage un peut intensif du client RSS, ca va me permettre de faire des corrélations entre sources mais aussi de proposer à l'utilisateur de chercher dedans de façon tres evoluée.>>
Quelles corrélations entre sources ? Peux-tu me citer un exemple, je ne vois pas ce que tu veux dire. Quant à faire des recherches dessus, y a déjà google... Et même, tu vas vraiment avoir besoin de plus qu'une simple recherche de mots clés ou de regexp, éventuellement triée sur la date ? Est-il vraiment utile d'ajouter une DB juste pour ça ?
<<Pour un client mail je vois tout de suite l'usage, j'ai personnellement plus de 2Gb de mail [...]>>
Tu n'es pas un cas typique, mais un de mes potes est exactement comme toi, sauf que lui c'est depuis le début des années 90 je crois (je ne sais plus quand exactement). Tout son mail est au format mh, et je crois me souvenir qu'il indexe avec glimpse. OK, à ce niveau là une DB est bienvenue. Mais sur les 20Mb de mail (sans compter les attachements, bien sur) qu'a l'utilisateur moyen, je maintiens que ça n'en vaut pas la peine. Si tu vises plus large, à ce moment là tu fais un outil de recherche généralisé pour tout tes fichiers tant qu'a faire, pas juste ton mail. Et tu ré-invente longhorn ou google-sur-pc :-).
<<Il n'y qu'a voir avec quelle régularité un bon nombre d'applis corrompent leurs données, ou deviennent incapable de relire leur formats de fichiers entre deux versions.>>
Ouais, comme les DBs par exemple. La corruption de données ça arrive forcément un jour ou l'autre, la seule question c'est comment limiter le niveau d'emmerdement. Et là une DB est une mauvaise réponse, alors qu'un bon gros format texte bien neuneu, c'est pas trop dur d'y retrouver ses petits. Quand à l'évolution d'un format d'une version à l'autre, ben c'est au dev de se dermerder pour être backward compatible si il ne veut pas trop faire chier ses utilisateurs. Là aussi une DB ne va pas t'aider, si c'est pas le format de la DB qui change, c'est le format de tes datas dans la DB...
Après oui, faire un format de données c'est pas si simple, mais il y en a tellement d'existants que c'est bien le diable si tu ne peux pas trouver ton bonheur quelque part.
<<Sans compter que moult programmeurs préferent réimplementer leur propres fonctions plutot que tenter d'utiliser les fonctions évoluées des bibliothèques>>
Y a des clowns partout. Mais je n'ai jamais travaillé pour une boite qui aurait accepté qu'un dev perde du temps à recoder quicksort, ni vu un dev assez bête pour le faire, quelque soit le langage.
<<jeter un oeil à SQLite parceque c'est bien fichu et vraiment à connaitre pour LA fois ou ce sera peut être la réponse au problème du jour.>>
Entièrement d'accord. Là ou j'objecte, c'est quand on me dit que c'est tout le temps la réponse, ou presque.
[^] # Re: explosion du trokilometre
Posté par Guillaume Laurent . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 1.
Quelles corrélations entre sources ? Peux-tu me citer un exemple, je ne vois pas ce que tu veux dire. Quant à faire des recherches dessus, y a déjà google... Et même, tu vas vraiment avoir besoin de plus qu'une simple recherche de mots clés ou de regexp, éventuellement triée sur la date ? Est-il vraiment utile d'ajouter une DB juste pour ça ?
<<Pour un client mail je vois tout de suite l'usage, j'ai personnellement plus de 2Gb de mail [...]>>
Tu n'es pas un cas typique, mais un de mes potes est exactement comme toi, sauf que lui c'est depuis le début des années 90 je crois (je ne sais plus quand exactement). Tout son mail est au format mh, et je crois me souvenir qu'il indexe avec glimpse. OK, à ce niveau là une DB est bienvenue. Mais sur les 20Mb de mail (sans compter les attachements, bien sur) qu'a l'utilisateur moyen, je maintiens que ça n'en vaut pas la peine. Si tu vises plus large, à ce moment là tu fais un outil de recherche généralisé pour tout tes fichiers tant qu'a faire, pas juste ton mail. Et tu ré-invente longhorn ou google-sur-pc :-).
<<Il n'y qu'a voir avec quelle régularité un bon nombre d'applis corrompent leurs données, ou deviennent incapable de relire leur formats de fichiers entre deux versions.>>
Ouais, comme les DBs par exemple. La corruption de données ça arrive forcément un jour ou l'autre, la seule question c'est comment limiter le niveau d'emmerdement. Et là une DB est une mauvaise réponse, alors qu'un bon gros format texte bien neuneu, c'est pas trop dur d'y retrouver ses petits. Quand à l'évolution d'un format d'une version à l'autre, ben c'est au dev de se dermerder pour être backward compatible si il ne veut pas trop faire chier ses utilisateurs. Là aussi une DB ne va pas t'aider, si c'est pas le format de la DB qui change, c'est le format de tes datas dans la DB...
Après oui, faire un format de données c'est pas si simple, mais il y en a tellement d'existants que c'est bien le diable si tu ne peux pas trouver ton bonheur quelque part.
<<Sans compter que moult programmeurs préferent réimplementer leur propres fonctions plutot que tenter d'utiliser les fonctions évoluées des bibliothèques>>
Y a des clowns partout. Mais je n'ai jamais travaillé pour une boite qui aurait accepté qu'un dev perde du temps à recoder quicksort, ni vu un dev assez bête pour le faire, quelque soit le langage.
<<jeter un oeil à SQLite parceque c'est bien fichu et vraiment à connaitre pour LA fois ou ce sera peut être la réponse au problème du jour.>>
Entièrement d'accord. Là ou j'objecte, c'est quand on me dit que c'est tout le temps la réponse, ou presque.