Base de données en C++

Bonjour,
j'ai besoin de stocker dans un fichier des structures, de pouvoir accéder rapidement à une de ces structures au moyen de clés, de la modifier et de modifier le fichier en conséquence.
J'ai seulement 300 structures à stocker, je me demande donc si le xml convient (en utilisant la librairie libxml) malgré la lenteur d'accès aux données ou s'il existe mieux.

Voici le type de structure que je veux stocker :

fichier station.x

Code:

---

1 2 3 4 5 6 7 8 9

struct station { string nom; float latitude; float longitude; float altitude; int age; int nb_param_obs; }

---

J'ai besoin d'accéder rapidement à la structure correspondant à une station donnée, sur le critère de son nom par exemple.

J'ai déjà essayé le format xdr, en utilisant rpcgen station.x, qui me génère du code en C (à condition que nom soit un char* et pas un string) pour lire et écrire mes structures dans le format xdr.

Je cherche la solution la plus rapide...

Et pourquoi pas directement en format binaire ?

Tu peux aller voir du côté de SQLite pour quelque chose de léger et sans serveur.

oui, mais il me faut réécrire tout le fichier une fois l'une de mes structures modifiées, non ?

merci Julien, je vais regarder ça.

Salut,
C'est une appli PC ou embarquée ?

Pour seulement 300 entrées sur une aussi petite structure, XML fera largement l'affaire même si tu dois régénérer tout ton fichier. Je ne connais pas SQLite mais n'est ce pas un marteau pour écraser une mouche vu le peu volume de tes données ? Charger 300 entrées dans un conteneur (vector, tr1::array ou map si tu utilises ton nom comme index) à partir d'un XML et les sauvegarder seront des actions transparentes pour l'utilisateur sur PC.

SQLite c'est justement la tapette pour ce qui est la gestion de base de donnée. C'est pas fait pour gérer d'énormes bases de données, ça va très bien pour les très petites.

D'ailleurs, c'est le SGBDR le plus utilisé du monde. Il est dans Firefox, dans Thunderbird, et énormément de logiciels de gestion local.

Son but c'est pas la rapidité (bien qu'il le soit assez pour des petites structures comme énoncé ici) mais de fournir une passerelle SQL pour la gestion de données dans un fichier.

Plus à se soucier de la sérialisation ni quoi que ce soit, en fait, et ça permet de passer outre la recherche fastidieuse dans un fichier xml.

Bonjour,

oui, moi, j'ai fait ça en MySQL, mais ça doit être kif. Une table des champs, une table des structures, puis n tables avec les contenus implémentés par des ordres create/alter table lorsqu'une structure est créée/modifiée.

Je pense que vous avez tous mal compris tonio_a_588. Il a parle de 300 structures, étant entendu qu'une structure est l'équivalent d'une tabe SQL. Vous semblez avoir compris qu'il n'y avait que 300 records d'une seule structure...

Il n'a pas parlé de son volume de données, mais j'ai l'impression qu'il s'est procuré quelque chose comme la cartographie de l'Europe chez téléatlas ou navtek ;)

EDIT: bof, non, c'est plutôt moi qui ait mal compris :calim2:
Il dit qu'il a "seulement" 300 structures. Moi quand j'ai 300 structures déclarées dans un projet C++ avec le mot clé struct ou class je sature un peu...

Citation:

---

Envoyé par camboui

Il dit qu'il a "seulement" 300 structures. Moi quand j'ai 300 structures déclarées dans un projet C++ avec le mot clé struct ou class je sature un peu...

---

Autant il aurait dit j'ai "plus de 20 structure", j'aurais compris comme toi, autant là, "que 300 structures", je pense qu'il parlait effectivement de 300 instances ;)

Citation:

---

Envoyé par tonio_a_588

oui, mais il me faut réécrire tout le fichier une fois l'une de mes structures modifiées, non ?

---

Je vois pas pourquoi.... Si tu compte faire uniquement des sauvegardes; et que tu ne compte pas vérifier ton fichier de l'extérieur, c'est possible en binaire. Par contre, à toi de gérer buffer et autre. Plus casse c*****e, mais niveau perf, t'aura pas mieux.

SQLite me semble idéal pour faire ça. Côté rapidité, c'est correct, et la BD est dans un unique fichier facilement déplaçable au besoin. Si la taille de la BD augmente un peu trop, une migration vers un SGBD "normal" reste relativement simple à faire.

Ce sera toujours moins lourd que n'importe quelle librairie de gestion XML, et plus pratique que n'importe quel container STL qu'il faudra sérialiser plus ou moins à la main...

ca dépend de ce que tu comptes faire avec les instances plus tard; des recherches, des insertions, etc ? dans ce cas SQLite
mais si c'est juste a serialiser, deux opérateur << bien placés suffisent, donc pas de marteau pour ecraser une mouche comme dirait 3DArchi
si la seule opération de recherche est une recherche sur le nom, un map et un opérateur << ou deux quoi.