J'ai un exemple simple, j'ai un client qui fait de la veille pour lequel on etudie un outil.
Il est intéressé à stocker les feeds d'info(Reuter par exemple) auquels il est abonné et quelques feeds RSS et des listes de brevets.
Il veut pouvoir taper dedans pour sortir: les articles écrits par le professeur bidule ou les entrées qui mentionnent le labo de bidulotique entre le 42 janvier et 54 fevrier, ou les articles donc les intervenants sont mentionnés dans des publications comportant le mot clé machinosetriphasée...
C'est un besoin qui dépasse le simple client RSS, mais avec la généralisation du format je ne serai pas surpris de voir pas mal de monde thésauriser les feeds pour retrouver des articles.
C'est sur on peut tout stocker en XML ou un format texte, mais pour de la recherche structurée c'est pas l'extase.
Pour le mail, il me semble que la popularité de l'annonce de GMail est la preuve que mon genre de mailomanie n'est pas si exceptionnel.
D'expérience, ces derniers mois, 20Mo c'est plutot le courrier de la semaine d'un utilisateur pas la totalité de ses archives de courriel.
En ce qui me concerne, j'indexe toutes les nuits le mail en tenant compte des infos structurées : FROM, TO, SUBJECT, MAIL-ID, MIME-PARTS ... Du coup je peux interroger la base pour sortir les emails avec un attachement en .PPT envoyés par machin (pour retrouver toutes les bonnes blagues qu'on m'a envoyé).
En cherchant le texte brut je perds la structuration. II y'a bien des outils pour chercher dans les mailbox mais c'est long et lent surtout quand tu recherches sur moult fichiers.
Bref mon bidule est un petit outil en ligne de commande d'un intéret tellement insignifiant que je suis le seul utilisateur, mais je m'en sers trés régulièrement et ca marche de façon simple, pas besoin de Google ou WinFS (ou BeFS) et c'est substanciellement plus rapide que la recherche depuis un client mail. Utiliser SQLite m'a permis de le faire en quelques heures de boulot au lieu de quelques jours si j'avais du coder les détails.
Pour la corruption de données, je pense surtout a celles dues à des bugs ou des problèmes de régression. J'en ai rencontré pas mal en particulier dans des softs "sur mesure" réalisés par des SSII aux contraintes de temps trop serrées mais aussi dans des grandes applications, censées être fiables.
L'idée de se baser sur une lib deja existante permet de déporter le problême : plus de monde qui rencontre les bugs implique plus de chance que ceux -ci soient corrigés sans avoir à le faire soit même, qui plus est qui dit upgrade du format dit outils de migration, ne pas avoir à les réaliser est un sacré gain de temps.
Si ce format est une BDD, dans pas mal de cas ca me parait avantageux.
Evidemment ca ne réponds pas à tous les besoins, mais même pour des quantités d'info moyennes l'économie de code complexe (recherches, tris, arbres, skip-list ou table de hashage) est une réduction considérable de risque de bugs. Je ne sais pas pour toi, mais personnellement, je trouve un rapport direct entre la quantité de code que j'écris et le nombre de bugs.
Pour les clowns, j'ai deja récupéré des projets sous-traités à la petite semaine, développés par des gars reconvertis informaticiens en 6 mois et qui avaient eu un cours de C with class pompeusement nommé C++ et qui n'avaient jamais entendu parler de namespace et encore moins de containeurs de la lib standard.
Alors évidemment, #include <algorithm> et utiliser des iterateurs c'est semble plus compliqué que de magouiller un truc bizarre avec une double liste chainée maison ( en plus une liste utilisée pour des pour des accés aléatoires) dans de telles conditions.
Bref du code moisi, c'est fréquent, et quand on utilise une librairie ad-hoc pour le boulot ca laisse moins d'opportunité de se tirer dans les pieds (enfin ca requiers 3 notions de SQL qui ne sont pas données à tous le monde mais tout de même ...).
Enfin au final je pense que nous sommes d'accord, ca n'est pas une solution universelle mais ca peut servir.
[^] # Re: explosion du trokilometre
Posté par Christophe Renard . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 5.
Il est intéressé à stocker les feeds d'info(Reuter par exemple) auquels il est abonné et quelques feeds RSS et des listes de brevets.
Il veut pouvoir taper dedans pour sortir: les articles écrits par le professeur bidule ou les entrées qui mentionnent le labo de bidulotique entre le 42 janvier et 54 fevrier, ou les articles donc les intervenants sont mentionnés dans des publications comportant le mot clé machinosetriphasée...
C'est un besoin qui dépasse le simple client RSS, mais avec la généralisation du format je ne serai pas surpris de voir pas mal de monde thésauriser les feeds pour retrouver des articles.
C'est sur on peut tout stocker en XML ou un format texte, mais pour de la recherche structurée c'est pas l'extase.
Pour le mail, il me semble que la popularité de l'annonce de GMail est la preuve que mon genre de mailomanie n'est pas si exceptionnel.
D'expérience, ces derniers mois, 20Mo c'est plutot le courrier de la semaine d'un utilisateur pas la totalité de ses archives de courriel.
En ce qui me concerne, j'indexe toutes les nuits le mail en tenant compte des infos structurées : FROM, TO, SUBJECT, MAIL-ID, MIME-PARTS ... Du coup je peux interroger la base pour sortir les emails avec un attachement en .PPT envoyés par machin (pour retrouver toutes les bonnes blagues qu'on m'a envoyé).
En cherchant le texte brut je perds la structuration. II y'a bien des outils pour chercher dans les mailbox mais c'est long et lent surtout quand tu recherches sur moult fichiers.
Bref mon bidule est un petit outil en ligne de commande d'un intéret tellement insignifiant que je suis le seul utilisateur, mais je m'en sers trés régulièrement et ca marche de façon simple, pas besoin de Google ou WinFS (ou BeFS) et c'est substanciellement plus rapide que la recherche depuis un client mail. Utiliser SQLite m'a permis de le faire en quelques heures de boulot au lieu de quelques jours si j'avais du coder les détails.
Pour la corruption de données, je pense surtout a celles dues à des bugs ou des problèmes de régression. J'en ai rencontré pas mal en particulier dans des softs "sur mesure" réalisés par des SSII aux contraintes de temps trop serrées mais aussi dans des grandes applications, censées être fiables.
L'idée de se baser sur une lib deja existante permet de déporter le problême : plus de monde qui rencontre les bugs implique plus de chance que ceux -ci soient corrigés sans avoir à le faire soit même, qui plus est qui dit upgrade du format dit outils de migration, ne pas avoir à les réaliser est un sacré gain de temps.
Si ce format est une BDD, dans pas mal de cas ca me parait avantageux.
Evidemment ca ne réponds pas à tous les besoins, mais même pour des quantités d'info moyennes l'économie de code complexe (recherches, tris, arbres, skip-list ou table de hashage) est une réduction considérable de risque de bugs. Je ne sais pas pour toi, mais personnellement, je trouve un rapport direct entre la quantité de code que j'écris et le nombre de bugs.
Pour les clowns, j'ai deja récupéré des projets sous-traités à la petite semaine, développés par des gars reconvertis informaticiens en 6 mois et qui avaient eu un cours de C with class pompeusement nommé C++ et qui n'avaient jamais entendu parler de namespace et encore moins de containeurs de la lib standard.
Alors évidemment, #include <algorithm> et utiliser des iterateurs c'est semble plus compliqué que de magouiller un truc bizarre avec une double liste chainée maison ( en plus une liste utilisée pour des pour des accés aléatoires) dans de telles conditions.
Bref du code moisi, c'est fréquent, et quand on utilise une librairie ad-hoc pour le boulot ca laisse moins d'opportunité de se tirer dans les pieds (enfin ca requiers 3 notions de SQL qui ne sont pas données à tous le monde mais tout de même ...).
Enfin au final je pense que nous sommes d'accord, ca n'est pas une solution universelle mais ca peut servir.