je souhaiterais réaliser à intervalle régulier des enregistrement immuables (jamais modifié), mais je me pose la question du stockage et de l'accès. D'un coté, j'ai DBM et je réaliserai un fichier DBM par enregistrement. L'inconvénient, c'est que comme les donénes sont strockées sous forme de paires et que j'ai plusieurs champs à enregistrer, il faut que je parse avant de pour exraire mes données. De l'autre coté MySQL: et là je ne sais pas comment prendre le problème: une table par enregistrement? j'ai peur que ça fasse beaucoup de tables (meme au rythme de 1 table/semaine). L'accès est simplifié masi c'est peut être un peu trop lourd pour ce que j'ai besoin.
 
Alors je voudrais votre avis: DBM, MySQL, ou autre chose. Si MySQL, quelle organisation?
 
 

Comment sont organisées tes données ?

comment vont etre? ben pas grand chose, mais c'est pas encore fixé: sans doute une petite douzaine de statistiques numériques, bien que ça puisse etre beaucoup plus. mais la n'est pas la question pour moi, c'est de savoir quel type de BD est adapté? parce que créer une table par semaine, ça me parait un peu démesuré surtout si elle ne sera utilisée qu'en consultation. fianlement, mon problème peut se résumer à : pour faire des logs, il vaut mieux DBM ou MySQL?

En fait, je ne vois pas pourquoi tu veux utiliser une table par relevé? pourquoi pas simplement une entrée par table?

ben par ce ca risque de faire une entrée super longue et pas facile à manipuler. chaque enregistrement que souhaite faire va etre composé d'une centaine d'entrées: je veux pouvoir accéder à ces données facilement et rapidement pour pouvoir faire éventuellement des recoupement ou des recherches globales. c'est pas un simple log

Alors utilise mysql, comme ça, tu pouras plus tard faire très facilement des comparaisons pour voir l'évolution de la fréquentation.

c'est pas ce que je veux faire.

Ben le plus simple, c'est de rajouter les lignes de log dans des fichiers mais c'est le moins souple.
Si t'as besoins d'y accéder sans faire de sélections variables, fait comme ça.
Sinon, si t'as besoin de sélectionner des périodes de logs variables, le plus simple au moment de la sélection sera de passer par une base de donnée telle que mysql.

personne veut comprendre: je veux mémoriser périodiquement un ensemble de données comme ce qu'on peut trouver dans une table (plusieurs champs) et y accéder en lecture comme dans une table: par exemple, mémoriser chaque jour le programme télé dans une structure de base de données afin de pouvoir en extraire des informations. Je veux savoir quoi utiliser: DBM ou MySQL? Mais comment faire? avec DBM, c'est simple, je fais une DB par enregistrement. Par contre, je ne vois pas comment faire avec MySQL si ce n'est créer une table par enregistrement: mais j'ai peur que ça soit un peu disproportionné, bien que l'accès soit plus facile qu'avec DBM. Je voulais bénéficier de l'expérience de ceux qui sont confrontés à un problème similaire: apparemment personne. Bon, ben je vais faire avec DBM...

Y'a pas de raison de s'énerver !
 
"Pourquoi une table par enregristrement ?" me semble une bonne question.
 
Si tes enregistrement n'ont pas le même structure on peut le comprendre, mais c'est pas certain pour autant.
 
Plusieurs tables avec des lien pourrait peut-être faire l'affaire, je ne sais pas. Faudrait avoir une idée plus précise de le structure de tes données.
 
Comment vas-tu faire tes requêtes ?
 
Par exemple, moi pour les logs, j'ai utilisé la technique suivante:
 
Une table avec 2 champs :  
un timestamp
un blob
 
Comme ma gestion des infos de la log sont dans un tableau PHP, je le sérialise, et je l'enregistre dans le blob. Le timestamp me permet de le retrouver.
 
remarque : La sérialisation peut aussi être utile pour stocker l'état d'un objet PHP.

 
c'est sur qu'avec cette utilisation auquelle j'ai déjà pensé, une seule table suffit. le problème est que mon blob va contenir beaucoup d'informations (une centaine d'entrées contenant 1 id, 100cararactères, 10 nombres flottants, 5 nombres entiers). si je veux rassembler toutes les infos disponibles correspondant à 1 id précise, ca beaucoupd e travail d'extraire tout ca des blob. je teste DBM, ça a l'air de marcher assez bien

 
Ben c'est pour çà que je proposais aussi une solution à plusieurs tables:
 
Une pour ton enreg principal, et une pour tes "entrées" !

j'avais pas vu et j'y avais pâs pensé: chui con comme la lune    
 
merci!

C'est l'heure qui veut çà !
 
Va dormir un peut sinon demain t'aurras tout plein de méchant BUGS à corriger.