Discussion :

[gosseynaj]

Bonjour à tous,

Ma demande est simple : je développe en perl des traitements qui ont besoin de stocker et de manipuler des données dans des tables. Il m'arrive de travailler avec un serveur MySQL situé sur une autre machine et les performances sont très bonnes. Dans certains cas, j'ai besoin de faire des petits scripts qui utilisent une base de données d'une ou deux tables, pas plus, et que je peux avoir à déployer rapidement chez des clients, sans avoir besoin d'installer MySQL, ni de définir des structures de données très compliquées. Les besoins sont très simples.
J'ai récemment mis en place la connexion avec des fichiers dBase (DBF) et cela fonctionne. Le module DBI::Xbase utilisé sait très bien tout seul créer la table sur simple requête SQL, et le fichier DBF qui va avec. Seulement ce module est sommaire, les possibilités de requête sont limitées, et surtout, je ne crois pas que les tables générées utilisent des index. Je me suis rendu compte que certains scripts étaient très lents à l'exécution. Je me demande donc quel autre type de SGBD simple et sans installation préalable pourrait remplacer dBase/Xbase pour ce type d'utilisation :
- Créer via une requête "CREATE TABLE..." une table rapidement dans un fichier indexé.
- Accéder à ce fichier/cette table via des requêtes SQL classiques pour lire et écrire rapidement des données s'y trouvant.
- Les volumes de données traités sont très faibles. Ca me sert surtout pour éviter de stocker des infos en mémoire et c'est plus facile à manipuler.

Merci pour vos idées et vos conseils.
Gosseynaj.

[Sun.Wu.Kong]

Je ne sais pas si c'est possible avec perl mais je dirais sqlite

[Lolo78]

Je dirais aussi SQLite.

Le module Perl sqlite du CPAN intalle non seulement le driver de database mais aussi l'application SQLite elle-même, si bien qu'il n'y a rien d'autre à installer.

Cela dit, selon tes besoins, il est aussi possible qu'un simple fichier plat à charger dans un ou plusieurs hachage(s) soit une meilleure solution. L'accès aux données dans un hachage est bien plus rapide qu'un accès indexé à une base de données. Donc, tout dépend du type de requêtes que tu désires faire.

[gosseynaj]

Cela dit, selon tes besoins, il est aussi possible qu'un simple fichier plat à charger dans un ou plusieurs hachage(s) soit une meilleure solution. L'accès aux données dans un hachage est bien plus rapide qu'un accès indexé à une base de données. Donc, tout dépend du type de requêtes que tu désires faire.

Merci pour les réponses.
En disant "fichier plat", tu penses à quoi, à un fichier texte ? Je pense pas que ça va aller, parce que j'ai vraiment besoin de stocker des données à plusieurs colonnes, du type avec des dates, des montants, des valeurs que je récupère et que je manipule. Ca revient presque à stocker des données en mémoire finalement, ce que je veux éviter, mais j'y besoin d'y accéder très souvent parce que lors du traitement, je lis des fichiers texte que j'analyse, et qui peuvent contenir plus de 100.000 lignes. Après, la lecture de ces fichiers est très rapide parce que Perl est très bon pour traiter des fichiers texte, et il ne faudrait pas que l'accès à ces données cumulées ralentissent le traitement. En gros pour chaque ligne du fichier texte en entrée lue, je dois accéder à une table de cumul. Donc si j'ai 100.000 lignes lues, je vais peut-être accéder 100.000 fois à cette table, pour y chercher et/ou y stocker des données. Et il ne faut pas que le traitement dure 20 min...
Avec MySQL, c'est très rapide, mais il faut avoir un serveur MySQL sous la main. Alors SQLite est peut-être la solution. Je vais y jeter un oeil.
Merci.

[Lolo78]

Par fichier plat, je veux dire un fichier texte de type CSV (données organisées par ligne et séparées par des séparateurs adéquats, par exemple des ";" ou des ",").

Pour le reste, tout dépend de l'utilisation qui sera faite et de la complexité des données. Mais, comme tu le dis toi-même, charger un fichier de 100 000 lignes en mémoire est très rapide. Et, avec une bonne structure de données en mémoire (hachages, hachages de hachages, etc.), tu peux obtenir des performances 10 à 100 fois supérieures à celles d'une base de données. Et rien de spécial à installer chez ton client.