Discussion :

[tintin72]

Bonjour,

J'ai un programme qui doit archiver et gérer (recherche, tri etc..) une collection de cd musicaux (300 environ), mais je ne sais pas vraiment quelle alternative choisir.

J'ai d'abord pensé interfacer mon appli avec une base de données genre mySql, mais est ce que c'est pas un peu démesuré par rapport à la quantité d'information à traiter ?
Sinon j'ai aussi pensé créer ma propre base de données (stocker l'information dans un fichier txt, puis créer des algoritmes de recherche, tri etc... avec des listes chainées par ex).

Laquelle de ces 2 solutions vous paraît la mieux adaptée ?

Merci

[Jean-Marc.Bourguet]

Je vais en proposer une troisieme: http://www.sleepycat.com

[epsilon68]

et moi une quatrieme, plus facile que la troisieme, SQLite !
elle permet de faire des queries avec du SQL
et Qt a un driver pour cette DB aussi.

a+

[tintin72]

Merci pour vos réponses

Je ne connaissais pas du tout ces 2 bases de données. Elles m'ont l'air trés intéressantes.
Donc en gros vous me conseiller plutôt de laisser tomber l'option "base de données faite à la main" ?

[Jean-Marc.Bourguet]

Pas necessairement. Ca depend de tes objectifs. Si l'apprentissage est un objectif important, tout faire soi-meme n'est pas un mauvais choix.

[epsilon68]

avant d'apprendre a faire une base de données, il vaut mieux apprendre a en utiliser une.

Je pense donc oui il vaut mieux ne pas faire un truc a la main, a moins deja de bien maitrisé les DB, de voir quelques limites, et d'en refaire une avec certaines contraintes.

[Jean-Marc.Bourguet]

avant d'apprendre a faire une base de données, il vaut mieux apprendre a en utiliser une.

Je pense donc oui il vaut mieux ne pas faire un truc a la main, a moins deja de bien maitrisé les DB, de voir quelques limites, et d'en refaire une avec certaines contraintes.

Mon opinion est differente. Avoir fait a la main un exemple simple (et une collection perso de CD est un exemple simple) permet d'avoir une bien meilleure comprehension des problemes qu'un SGDB traite (c'est valable pour d'autres outils puisssants aussi). Sans cette experience, je constate deux tendances, parfois combinees,
- une mauvaise comprehension de ce que font les outils
- vouloir utiliser des outils dans des cas tellement simples qu'ils sont plus une gene qu'un avantage.

[tintin72]

J'ai déjà fait une base de données 'à la main' . C'était pour un classique carnet d'adresse, et ça fonctionnait plutôt bien.
Cependant pour ce projet (qui risque de s'agrandir) je voudrais quelque chose de rapide et d'efficace. C'est pourquoi j'aimerais savoir si on peut créer une base de données aussi performante que celles mentionnées (sans pour autant entrer dans un projet tentaculaire).

[loufoque]

300 semble être un nombre suffisamment raisonnable pour travailler en mémoire et pas avec des fichiers.

[KiLVaiDeN]

Salut,

Perso je suis du même avis que Jean-Marc si tu souhaites te former, fait plutot la solution 2.

Pour que ton application soit bien modulable, et qu'un jour tu puisses passer vers une vraie base de données, fait bien attention à utiliser des bonnes structures de données que tu pourras ensuite calquer facilement sur une BDD au lieu de tout refaire. Ca t'évitera beaucoup de travail.

A+

[tintin72]

300 semble être un nombre suffisamment raisonnable pour travailler en mémoire et pas avec des fichiers.

Le truc c'est que je voudrais implémenter une fonction de recherche par chanson. En considérant qu'il y a en moyenne 10 chansons par album on arrive à 3000 entrées environs.
Penses tu que ce soit encore raisonnable pour travailler en mémoire ?

Perso je suis du même avis que Jean-Marc si tu souhaites te former, fait plutot la solution 2.
Pour que ton application soit bien modulable, et qu'un jour tu puisses passer vers une vraie base de données, fait bien attention à utiliser des bonnes structures de données que tu pourras ensuite calquer facilement sur une BDD au lieu de tout refaire. Ca t'évitera beaucoup de travail.

La petite base de données que j'avais créée fonctionnait sur le principe:
- stockage des informations dans un fichier txt
- récupération et gestion de ces information via une liste chainée
(les différentes informations étaient séparées dans le fichier txt par des caractères spéciaux).

Maintenant je ne sais pas si ce système rudimentaire est bien adapté pour mon nouveau projet.
En particulier la mise en mémoire qui me paraît un peu lourde.
J'ai cherché des exemples de création de base de données en C++, mais en fait c'est toujours pour interfacer des DB comme Sql, mySql, Oracle etc....
Connaitrais-tu des exemple concrets de création de base de données entièrement en C++ ?

[epsilon68]

SQLite permet de travailler en memoire aussi,
cad de creer une table en memoire de mettre des enregistrements puis de faire des selects dessus.

Regarde comment elle marche puis tu aviseras si tu dois refaire (j'avais ecrit refoire ) une database a la main !

Enfin ce n'est que mon avis.

a+

[epsilon68]

Sans cette experience, je constate deux tendances, parfois combinees,
- une mauvaise comprehension de ce que font les outils
- vouloir utiliser des outils dans des cas tellement simples qu'ils sont plus une gene qu'un avantage.

souvent ce que j'ai vu, c'est de la non-connaissance de ce qui existe autour.
et bloqué par manque d'imagination dans leur implementation.

[KiLVaiDeN]

Maintenant je ne sais pas si ce système rudimentaire est bien adapté pour mon nouveau projet.
En particulier la mise en mémoire qui me paraît un peu lourde.
J'ai cherché des exemples de création de base de données en C++, mais en fait c'est toujours pour interfacer des DB comme Sql, mySql, Oracle etc....
Connaitrais-tu des exemple concrets de création de base de données entièrement en C++ ?

Salut,

Quelque soit le système que tu mets en place ( listes chainées, arbres binaires, etc... ) le plus important est d'avoir une structure en MVC qui te permettra d'évoluer vers d'autres moyens au niveau "accès aux données".

Je m'explique : Il te faut une batterie d'objets "conteneurs" qui contiendront les données de ton programme. Ces objets seront alimentés par une "couche modèle" ( le M dans MVC ) qui elle se chargera d'utiliser la technologie que tu voudras. Si tu bases ton application sur cette architecture, tu pourras changer ton système d'accès aux données simplement en ne modifiant uniquement que la couche modèle, car tes objets conteneurs resteront les mêmes.

A+