Bonjour,

je réalise un formulaire avec un calendrier trimestriel. pour chaque date j'ai un champ text.
je souhaite sauvegarder dans une base de données, mais je m'interroge sur la manière.

La table calendrier (simplifiée)
une colonne date (time) et une colonne text_date

Façon1:
j'enregistre pour chaque date(jour) le champ text, donc 365 tuples.

Façon2:
j'enregistre une seule date (la date du premier jour du premier mois du trimestre) et dans la colonne text_date, j'enregistre un array comportant tous les champ text du trimestre. Donc 1 seul tuple.


Quelle est, d'après vous, la "bonne" manière de faire.
Quelle est la plus rapide pour l'enregistrement et/ou la lecture.

Merci

Ben ... ça va surtout dépendre de ce que tu veux en faire ensuite.

Si tu dois lire les informations sur tous les trimestres d'un coup, si tu ne dois jamais faire de comparaison entre le contenu d'un trimestre avec un autre, ... tu peux utiliser un array.

Maintenant, est-ce que tu as besoin d'un datetime ? Un champ numérique (20081, 20082, ...) ou texte (2008T1, 2008T2, ...) peut également être utilisé.

Merci d'avoir répondu Caroube.

Si tu dois lire les informations sur tous les trimestres d'un coup, si tu ne dois jamais faire de comparaison entre le contenu d'un trimestre avec un autre, ... tu peux utiliser un array.

Pour l'instant une lecture des informations par trimestre me suffit. Mais, il est vrai qu'après usage, d'autres "demandes" (de la part des utilisateurs du calendrier) pourraient être formulées. Donc, il vaut peut-être mieux anticiper une exploitation future des données.

Je pense m'orienter vers un enregistrement de 365 tuples. Ce qui m'inquiète dans ce choix, c'est un temps d'insert et de select qui risque d'être un peu long (à tester).

Si tu commences à avoir des problèmes de temps de réponse sur 365 enregistrements de base de données, un conseil : change de serveur, celui-là est mort

Ben, je me suis trompé, c'est pas 365 enregistrements, mais environ 90 pour un trimestre.
A priori, 90 enregistrements, ça devrait par faire peur à la bd et au serveur. :-))))
Mais, si je prévoie que chaque user peut enregistrer chacun de ses trimestre, alors sur 3 ans on arrive à : 4*3*90*x users (par ex. 200)=216000 enregistrements pour une table.
Dans la mesure, où je n'ai pas beaucoup d'expérience avec les bd (mysql), je m'interroge :-(((

Merci Caroube d'avoir répondu

200.000, ce n'est rien du tout pour une base de données. Pour t'en convaincre, il te suffit de remplir table avec 200.000 enregistrements (une petite boucle PHP et ça roule ...). On commence à se poser des questions sur les temps de réponse quand on atteint les millions d'enregistrement. Et en général, on trouve des réponses.

Tu amélioreras les performances en mettant un (des) index sur les colonnes qui servent à retrouver les informations (celles qui apparaissent dans les clauses WHERE).

Mais dans ton processus : saisie de critères par l'utilisateur, transmission au serveur, extraction des données, mise en forme, renvoi du résultat à l'utilisateur, ce n'est pas l'extraction via SQL qui posera le plus de problème au niveau du délai.

Je suis convaincu.
L'idée de faire un test de x enregistrements pour connaître le temps de latence de la bd, est plus explicite que n'importe quel discours, je n'y avais pas pensé et c'est simpliste.

Merci beaucoup pour le tuyau Caroube.
Bonne continuation

Et si tu enregistres que les événements et leur date, et pas les autres. Je m'explique :

Un utilisateur crée un événement, disons pour le 20 janvier. Tu crées une ligne, avec un timestamp à cette date, et un champ texte avec le descriptif.
Pas besoin de créer une entrée par date, tu crées juste les entrées qu'il faut. Si un autre utilisateur ajoute à la même date, tu t'en fous, tu crées une autre entrée, il y aurau juste 2 entrées pour ce jour la.

Et à l'affichage c'est ton script php qui prends les relais, tu te débrouilles pour avoir un système qui t'affiche tous les mois, les jours et les années. Et quand dans ta boucle tu tombes sur le jour ou il y a un renseignement, ou plusieurs, tu affiches le bon événement au bon endroit.

Ce sera beaucoup plus léger non ?


(Ou alors je suis complètement à côté de la plaque ?)

Merci Lux, d'avoir pris le temps de lire et de proposer une solution pour alléger les enregistrements.
Je ne souhaite pas (et peux pas) alléger les enregistrements car à chaque jour correspondra un ou plusieurs "évènement(s)".
Pour l'instant , j'opte pour un enregistrement de chaque jour. Mais, je ferais un essai au préalable comme me la suggéré Caroube.
Bonne continuation à tous