Salut !
 
Je souhaiterai faire une appli sous RAD 07 en C++ ayant pour but de répertorier Bluray, Jeux PS3, CD et DVD. En gros je voudrais une sorte d'album comme Movie Collector pour ceux qui connaissent.
La base de données de l'appli sera locale et contiendra les infos allociné pour les films, Jeuvideo.com pour les jeux PS3 et un équivalent pour les CD audio. Les infos seront récupérées automatiquement par un script sur le site en question lors de la création d'une fiche pour le média, puis stockées dans la base de données pour être autonome en offline.
 
Bref, à prévoir, ça sera pour ~1000 fiches avec un résumé, durée, qualité, note perso, avis, etc.
 
Je cherche donc quelle serait la meilleure solution pour stocker tout ça sachant que je voudrais quelque chose de pas trop lent/lourd.
 
Je n'ai travaillé qu'avec les bases Paradox mais j'ai bien peur que ça soit limité et pas super fiable pour
Et en base déportées, j'ai travaillé sur oracle 9...
 
Des idées/conseils pour le choix de la base ? Access serait-il un bon choix ?
 
Merci    

personne peut me conseiller ?

N'importe quel SGBD peu convenir. Du coté des vrais gratuits tu as par exemple firebirdsql ou postgreSQL. Sinon il y à des éditions gratuites des autres SGBD. Si tu veux un tour d'horizon complet des SGBD tu peu lire ce comparatif sur les SGBD.

Le problème avec ce genre de comparo c'est qu'il y a tellement de choix qu'on ne sait plus vers quoi se tourner
As-tu un avis personnel sur quelques choix particuliers ?
 
Merci

je te conseilles SQLite, c'est gratuit, open-source, et ca marche bien
la preuve firefox stocke désormais pas mal de données sous sqlite, notamment l'historique et les bookmarks

ok merci, je vais regarder ça...

Salut, j'arrive un peu après la tempête.

En C++, je suppose que tu trouveras des libs pour sérialiser un objet du genre "DataSet" en XML.

Vu les performances que j'ai obtenu avec C#, pour une dizaine de milliers de lignes, tu peux partir confiant avec ce type d'architecture. Le gros avantage, c'est de ne pas nécessiter de programme/lib supplémentaire à déployer avec ton programme ni quoi que ce soit.

Non non tu n'arrives pas après la tempête ^^
 
Ok, je vais regarder aussi. Tu crois que ça serait plus perf qu'une solution sqlite comme en parle couak ?

Non, je doute que les perfs soient meilleures (c'est même pour ainsi dire sûr qu'elles seront inférieures)
 
Mais à raison de 1 Ko de données par fiche, si t'as 1000 fiches, ça fait 1 Mo... Donc niveau perfs, t'as peu de souci à avoir, faudrait vraiment que tu bosses sur un Goupil pour avoir des problèmes de perfs je pense.
 
En tout cas, j'ai mis en place une solution à base de DataSet sérialisés en XML pour un logiciel de rééditions d'étiquettes dans une chaîne de magasins, et malgré le nombre important de références (environ 10000) il n'y a pas le moindre problème de performances pour faire des recherches ou des mises à jours.

En même temps avec un vrai SGBD tu as aussi beaucoup plus de possibilités. Bref il y à pleins de solutions possibles la question est aussi avec quel genre d'outils tu veux travailler dans le futur, une fois que tu sera familiarisés avec un outil tu pourra t'en servir pour d'autres projets.

Pareil, je te conseille aussi fortement SQLite, ça te permettra pas mal d'avantage comme :

• Super rapide (fait gaffe aux index quand même, mais avec aussi peut d'enregistrement, ça ne posera pas de problème).
• Tu pourra faire des recherches et des jointures avec tes données dans tous les sens, et ce extrêmement facilement.
• Tu garde une marge énorme pour ce qui de l'évolution du schéma de données. Alors qu'en XML, tu vas en chier si jamais ton schéma de données n'est pas trop ce que tu voulais.
• L'empreinte disque (300Kb) /mémoire de la lib SQLite est minuscule, pratiquement celle d'un parseur XML. Et ça supporte pratiquement tout SQL92.
• Déploiement trivial (juste une dll, pas de serveur/compte à configurer).

Ok, ça me parait pas mal effectivement, je vais m'orienter vers sqlite je verrais bien au fur et à mesure
 
Merci pour vos conseils !

Ah, un truc à faire attention avec SQLite, c'est que par défaut il utilise un mécanisme de synchronisation avec le disque ultra paranoïaque. Ça ralenti considérablement les modifications (insert, update et delete) d'enregistrements, mais ça permet de garantir une certaine intégrité de la base. L'astuce est d'utiliser judicieusement les transactions ou au pire d'utiliser un mécanisme de synchronisation un peu moins brutal (genre "pragma synchronous=normal" au lieu de "pragma synchronous=full" (le truc par défaut)).
 
En général, ça surprends la première fois qu'on utilise SQLite.