Version imprimable
Bonjour,
J'ai un tableau généré dynamiquement en php et je souhaite le sauvegarder dans ma base de donnée mysql.
Le tableau est composé de 4 collones :
- les deux premières avec des noms et prénoms,
- les deux dernières avec des checkbox pour enregistrer les présences du matin et de l'après midi
Pouvez-vous me dire quelle est la méthode à utiliser pour sauvegarder tout le tableu dans ma BdD?
Merci d'avance !
si vous le générez en php, d'où vient la liste des personnes ?
Elle vient d'une autre table de ma BdD...
donc je suppose que la table a une clé primaire "id_utilisateur" et des champs comme cela ?
- id_utilisateur
- prenom_utilisateur
- nom_utilisateur
- email_utilisateur
- ...
à partir de ça il faut commencer par réfléchir à ce que vous voulez stocker comme informations dans la table des présences, par exemple :
1 25/08 matin 2 24/08 après midi 2 25/08 matin 2 25/08 après midi
ou peut être qu'il vaut mieux séparer le champ "présence" en 2 champs, 1 champ avec un timestamp et l'autre un booléen "matin / après-midi".
que vous voulez faire ensuite avec ces données ?
Dans la table 'presences' je souhaite stocker les noms, prénoms, presenceMatin et presenceAprem de manière à pouvoir les ré-afficher une à l'aide d'un tableau dynamique.
Les présences sont saisies grâce à des checkbox.
S'il existe des enregistrements dans la table presences pour la journée sélectionnée, je génère le tableau à partir de la table présences(nom, prenom, matin, aprem). Sinon, j'édite une liste à partir de la liste des utilisateurs pour saisir une nouvelle journée.
Voici le code pour récupérer les données et générer le tableau.
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Bonjour,
Il ne faut évidemment pas créer de redondance en stockant dans la table des présences les noms, prénoms et autres attributs déjà présents dans la table des personnes.
Dans une base relationnelle, les seules redondances autorisées sont les clefs étrangères
Avant de se focaliser sur les tables, il faut toujours commencer par réfléchir aux règles de gestion et à la modélisation conceptuelle qui en découle.
A priori les règles de gestion sont :
R001 : une personne peut être présente à plusieurs sessions
R002 : à une session peuvent être présentes plusieurs personnes
On a donc, au niveau conceptuel, un cas typique d'association de cardinalité maximale n de part et d'autre :
[PE_PERSONNE] 0,n --- (PA_participer) --- 0,n [SE_SESSION]
Ce faisant, au niveau tabulaire, on aura 3 tables : les personnes, les sessions et la table associative ayant pour PK l'identifiant de la personne et l'identifiant de la session.
Les tables sont donc (PK soulignées, FK suffixées #)
PE_PERSONNE : (PE_ident, PE_nom, PE_prenom, PE_ddn...)
SE_SESSION : (SE_ident, SE_dtdeb, SE_dtfin)
PA_PARTICIPER : (PE_ident#, SE_ident#)
Comme toujours, la PK de la table associative est composée des FK héritées des types d'entité au niveau conceptuel ;)