Discussion :

[E. Nigma]

Bonjour à tous,

J'ai un formulaire PHP rattaché à une bdd gérée avec MySQL. Ce formulaire va devoir être renseigné par 900 utilisateurs en un laps de temps plutôt court (quelques jours). Il ne me semble donc pas inévitable que plusieurs utilisateurs se retrouvent à valider leurs données en même temps.

Dans ce cas de figure, comment se comporte l'intégration en bdd :
Y a-t-il perte de données (les données d'un seul utilisateur sont montées en base et les autres tout simplement ignorées) ?
Ou alors les données sont placées dans une file d'attente et intégrées en bdd au fur et à mesure les unes après les autres ?

Par ailleurs le comportement de l'intégration en bdd dépend-il du type d'hébergement ? (je suis sur un hébergement mutualisé).

Merci par avance pour votre aide.
2lester

[CinePhil]

En principe, l'écriture sur une table bloque la table le temps que cette écriture soit faite. Les requêtes INSERT et UPDATE sont donc en principe traitées dans leur ordre d'arrivée au serveur.

Par contre, si l'application est mal développée, il peut y avoir des effets indésirables. Par exemple, le coup classique de la mise à jour d'une quantité...

1) L'utilisateur A interroge une quantité dans une table.
Ça donne par exemple 5.

2) L'utilisateur B interroge la même quantité dans la même table.
Ça donne toujours 5.

3) L'utilisateur A met à jour la quantité à partir du résultat obtenu en 1.
quantité = quantité - 2 = 5 - 2 = 3

4) L'utilisateur B met à jour la quantité à partir du résultat obtenu en 2.
quantité = quantité + 1 = 5 + 1 = 6

Si le programme fait effectivement une mise à jour à partir de l'état en temps réel de la colonne quantité, cela ne doit pas poser trop de problème (selon ce que signifie cette quantité quand même !) mais si le programme se contente de forcer la nouvelle quantité à partir du calcul qu'il a effectué, c'est comme si l'opération 3 n'avait jamais eu lieu.

[E. Nigma]

Merci CinePhil pour ta réponse.

Mon formulaire est vraiment tout bête (il s'agit d'un formulaire d'inscription à des activités) avec quelques inputs type text, checkbox et liste déroulante : par conséquent ma bdd est, elle aussi, simplissime.

Elle sera concernée principalement par des INSERT.
Chaque utilisateur pourra faire un UPDATE sur ses données personnelles, et ses données personnelles seulement. Pas d'UPDATE possible donc des mêmes données par différents utilisateurs.

Donc si j'ai bien compris ta réponse (excuse-moi je veux être bien sûre d'avoir compris, je débute dans ce domaine :
Si j'ai 3 utilisateurs (pour ne pas dire 50), A, B et C, qui font un SUBMIT de leurs données en même temps sur le formulaire : les données du 1er utilisateur, disons A, sont écrites en base. Pendant ce temps la base est bloquée en écriture mais les données de B et C sont en attente sur le serveur. Quand les données de A sont écrites, la table est de nouveau dispo pour écriture et les données du 2e utilisateur sont écrites, la table est de nouveau bloquée en écriture et ainsi de suite...

Donc il n'y a pas de perte de données c'est bien cela ?

Merci

[CinePhil]

C'est ça, mais...

il s'agit d'un formulaire d'inscription à des activités

N'y a t-il pas dans l'application une gestion du nombre maxi de participants à une activité ?
Auquel cas tu peux te retrouver confrontée au cas que j'ai cité dans mon précédent message !

1) A et B consultent les activités.
La page lui affiche les activités pour lesquelles il reste de la place.

2) A s'inscrit à l'activité 1 pour laquelle il reste 1 place.
Ouf ! se dit-il !

3) B s'inscrit à la même activité pour laquelle, selon son écran, il reste aussi une place.
Ouf ! se dit-il !

Sauf que si le système ne vérifie pas, à chaque inscription en BDD, qu'il reste toujours effectivement de la place, ça entraînera un surbooking !

Il faut donc a minima un trigger à l'insertion qui vérifie que le nombre d'inscrits max n'est pas déjà atteint et gérer l'éventuelle erreur renvoyée par le SGBD.

[E. Nigma]

J'aime bien le "Ouf ! Se dit-il !"
Oui l'appli gère ce cas du nombre max de places par activités, et j'ai mis en place un trigger en effet.

Merci pour tes conseils précieux CinePhil.