Quel meilleur stockage des données ?

Bonjour à tou·te·s,

Débutant en Python − avec dans une main l'ouvrage Rapid GUI Programming with Python and Qt, de l'autre les tutos de Développez.net − je vous soumets une question relative à la meilleure façon de stocker des données pour un projet.

Le projet en question mérite rapide présentation : il s'agit d'un logiciel d'aide à l'analyse de texte, à l'instar d'un vieillissant et abandonné Weft QDA ou bien, pour citer des logiciels payants (et chers !) et plus ambitieux aussi, NVivo ou encore QDA Miner.

En résumé le principe est le suivant : on dispose d'un corpus de textes en lecture seule − typiquement, des entretiens retranscrits, mais ce peut-être aussi des articles de presse, ou tout autre données textuelles rédigées − que l'on va « coder ». Dans le langage qui est le mien, celui des sciences humaines et sociales, l'opération dite de codage consiste à « étiqueter » des morceaux de texte (une phrase ou un ensemble de phrases) avec ce qu'on appelle donc un code et qui est, grosso modo, une catégorie servant à l'analyse. Par exemple, si j'ai des entretiens d'étudiants portant sur leur orientation universitaire, peut-être à l'analyse des dits entretiens vais-je devoir créer les codes « relation avec les parents », « déménagement », « scolarité lycéenne » ou d'autres choses encore. Très concrètement, l'opération est simple : il s'agit de sélectionner un segment de texte et, via un clic sur un bouton, de choisir le code associé à ce segment.

Pour finir la description, précisons qu'une fois la phase de codage terminée, la fonctionnalité de base consiste à produire des rapports : par exemple, l'ensemble des segments codés « déménagement » sur l'ensemble des entretiens retranscrits, ceci pour faciliter leur analyse et leur comparaison. Il ne s'agit ni plus ni moins que du remplacement de la vieille méthode à base de surligneurs, ciseaux et colle…
D'autres fonctionnalités plus avancées peuvent être imaginées (croisement de codes, croisement entre des codes et des variables appliquées aux différents entretiens, statistiques textuelles, etc.)

Ma question est double :

• Quel type de données est-il pertinent d'enregistrer ? Spontanément, je vois deux possibilités : soit ne stocker que les positions des segments dans le texte, soit stocker le segment lui-même (et donc dupliquer le contenu textuel qu'il représente). A priori la première solution est la plus légère en termes de stockage, mais je me demande si elle n'est davantage pas limitée. Par exemple, Weft QDA permet de coder un rapport : une fois que j'ai produit le rapport sur le code « déménagement », je peux le coder pour y appliquer des codes plus précis, plus fins. À la lumière des quelques indications que j'ai pu fournir, une solution (peut-être une troisième…) vous paraît-elle clairement plus avantageuse ?
• Sous quel format ? Là encore, spontanément, je considérerais l'alternative entre une base de données sqlite et un (ou plusieurs ?) fichiers XML. Les seconds me semblent posséder l'avantage de la « lisibilité » (si, pour une raison x ou y, l'utilisateur veut fouiller dans les données…) mais j'ai du mal à évaluer leur pertinence en termes de performance par rapport à un bdd et sa possibilité de faire des requêtes.

J'espère ne pas avoir été trop long et vous remercie :)

Salut,

Qui dit données dit modèle de données et base de données et éventuellement des algorithmes adaptés à vos traitements. Ce qui fait autant de forums/rubriques/techno. à visiter avant de coder quoi que ce soit (éventuellement avec Python).

- W

Bonjour,

Je suis d'accord avec la réponse de wiztricks, et j'ajoute ceci:

La présentation de problème est déjà bien, mais il manque une évaluation du volume des données à stocker. Ce volume aura une grande importance pour le choix des techniques à utiliser. Et au delà d'un certain volume (Go? To?), il faudra voir du côté des "big datas".

Quelques idées en plus:

- Les SGBDR (système de gestion de bases de données relationnelles) permettent de stocker les données de façon structurée, y compris en plusieurs tables avec des relations entre elles. Cela permettrait, par exemple, d'associer une même séquence de texte à plusieurs thèmes sans avoir à les stocker plusieurs fois. Il existe des méthodes pour choisir la bonne structure de données en fonction du problème (voir les forums spécialisés).

- A mon avis, ce qui est critique, c'est la capacité de retrouver les données rapidement quand on en a besoin. A partir d'un certain volume de données, cela condamne les solutions de type XML: seuls les SGBDR sont capables de faire ça. Un avantage supplémentaire, c'est que grâce à des langages de haut niveau comme SQL, on peut répondre facilement à des questions qui n'étaient pas prévues au début de l'étude (tant que ces questions sont compatibles avec la structure des données). On peut aussi modifier la structure des données en utilisant ces requêtes (ex: ajouter une table), ce qu'une programmation avec un langage non spécialisé (C, ...) rendrait pénible.

- Avec un volume de quelques centaines de Mo, sqlite est très bien: il est très rapide et déjà assez puissant pour faire des requêtes sophistiquées. Mais le choix entre sqlite et d'autres produits comme MySQL dépend surtout du critère suivant: est-ce que plusieurs personnes doivent accéder au même SGBDR en même temps? Si oui, cela condamne sqlite, et la solution d'un SGBDR sur un serveur est inévitable (MySQL, PostgreSQL, etc...).

- le choix du langage (Python et autres) est secondaire puisque la puissance du truc sera donnée surtout par le SGBDR lui-même ainsi que par la façon dont les données sont structurées. Mais Python saurait piloter ça sans problème. Puisque la bibliothèque Qt est dans les possibilités (PyQt avec Python), un avantage supplémentaire est dans la possibilité de représentation graphique des données (présentation de type tableur), non seulement des tables elles-mêmes, mais aussi et surtout des résultats des requêtes. J'utilise ça souvent avec PyQt, une base sqlite de 500Mo avec une douzaine de tables, des contraintes diverses et ça marche plutôt bien. On peut même faire des recherches de textes "similaires" (avec ratio de similitude) comme le fait si bien google dans ses propositions à nos demandes sur le web.

Bonjour,

Merci pour vos précieuses réponses ; visiblement, beaucoup de lectures m'attendent ! (d'ailleurs, si vous avez quelques liens à me proposer en priorité, je suis preneur, parce que là ce sont des bibliothèques entières qu'il me faut défricher).

Une petite précision avant de répondre sur le fond : c'est dans une optique d'apprentissage du langage Python que je me lance dans ce projet qui, de surcroît, est purement personnel. Le choix de Python est donc présidé par des critères indépendants du projet lui-même (je conçois qu'imposer l'outil indépendamment de l'objectif puisse paraître inverse à la logique lorsqu'on est un amateur éclairé ou un professionnel*!)

Concernant le volume des données : a priori, on parle de quelques dizaines de Mo. Un entretien retranscrit dans un traitement de texte occupe, à la louche, entre 25*et 45 pages. L'enquête qualitative d'un seul chercheur se base généralement sur un nombre d'entretiens inférieur à 50 voire 40. Les enquêtes collectives peuvent produire une centaine d'entretiens, mais c'est rarement beaucoup plus (et de toute façon, les chercheurs engagés dans de telles enquêtes emploient des logiciels pros). Voilà pour un ordre d'idée très approximatif : on est très loin d'atteindre le To, ni même le Go, et ce ne sont pas les informations supplémentaires (les codes et leur mise en forme associée, les variables caractérisant les interviewées, etc.) qui vont modifier drastiquement le poids total des données à stocker.

C'est d'ailleurs ce petit volume qui me faisait hésiter entre XML et sqlite, mais les possibilités évoquées par tyrtamos éclairent davantage la situation et laissent à penser que ce dernier pourrait être un bon choix (l'idée de recherche «*approximative*» m'intéresse beaucoup*!)