methode optimisée d'insertion de données

Salam; dans les sites web dynamiques y'a beaucoup de flux entre serveur est machine client , par exemple l'insertion de données:
l'utilisateur saisie des données ensuite les inserts dans la base de données.
par exemple dans mon cas :
j'ai un formulaire de 10 champs= ( donc un (01) enregistrement).
l'utilisateur valide le formulaire en moyenne trois (03) fois soit trois enregistrement l'un après l'autre.
l'application doit géré une moyenne de 500 utilisateur.
donc 500*3*10 !!!!!
est ce que il est souhaitable d'enregistré information après l’autre dans la BDD , ou il y'a une autre façon de collecté tous les enregistrements de l'utilisateur sur la machine client ensuite envoyé le tout dans la base de données?
:cfou:

Ça dépend.

Observes-tu des ralentissements ?
Comment sont effectuées les connexions à la base de données ?
Tes 3 requêtes sont-elles envoyées via 3 connexions différentes ou sur la même ?

Avec un bout de code ça aiderait.

Bonjour,

Dans ce cas de figure et pour éviter les appels multiples, j'utilise ce qui est offert par SQL pour les insertions :

Code:

---

INSERT INTO t_table (fieldA, fieldB) VALUES (valueA1, valueB1), (valueA2, valueB2), ... , (valueAn, valueBn);

---

Un seul appel, mais (n) enregistrements ajoutés.

Salut,

Je suppose qu'il s'agit d'un formulaire en trois étapes.

D'une part pour le ralentissement possible en surchargeant le serveur, et d'autre part pour la cohérence des données, je te suggérerais de stocker tes informations en SESSION (genre tes trois requêtes) et de les effectuer en même temps :

- Tu es sur que toutes tes données sont présentes
- Tu fait qu'un appel à ton SGBD et donc optimise le temps de réponse.

Bien sur, t'auras toujours 3 requêtes à exécuter, mais d'un coup, donc plus rapide je pense ;)

Salam ; Marc3001:

Citation:

---

Observes-tu des ralentissements ?

---

j'ai pas encore testé , seuelemnt je cherché la bonne methode de faire ça (rien ne remplace l'expérience).

Citation:

---

Comment sont effectuées les connexions à la base de données ?

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

<?php // On se connecte à la bdd try { $PARAM_hote='localhost'; // le chemin vers le serveur $PARAM_nom_bd='essai'; // le nom de votre base de données $PARAM_utilisateur='root'; // nom d'utilisateur pour se connecter $PARAM_mot_passe=''; // mot de passe de l'utilisateur pour se connecter // connexion marche trés bien avec affichage de msg erreure   // Options de connection $options = array ( PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8" , // indiquer à MySQL que echanger nos données en UTF8. PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION , PDO::ATTR_PERSISTENT => true );     $cbd = new PDO('mysql:host='.$PARAM_hote.';dbname='.$PARAM_nom_bd, $PARAM_utilisateur, $PARAM_mot_passe , $options ); }   catch(PDOException $e) { echo 'Une erreur de connexion est survenue !'; $e->getMessage(); die(); } $cnx = null; // Fermeture de la connexion ?>

---

Citation:

---

Tes 3 requêtes sont-elles envoyées via 3 connexions différentes ou sur la même ?

---

non !!! c'est la même.
rawsrc:

Citation:

---

Dans ce cas de figure et pour éviter les appels multiples, j'utilise ce qui est offert par SQL pour les insertions :

---

l'utilisateur peut valider un seul enregistrement ou N fois , là je peut pas cerné le nombre de fois.
selont ton code je crois que je dois faire une boucle non !!!!
Nawwis:

Citation:

---

Je suppose qu'il s'agit d'un formulaire en trois étapes.

---

non il s'agit d'un formulaire avec 10 champs , le tous = un seul enregistrement.
si l'utilisateur a un seul enregistrement de 10 champs il le valide sinon s'il a n enregistrements donc il doit validé n fois une prés une.
afin d'éviter les n appels , je cherche une methode afin d'optimisé l'enregistrement (genre panier) une fois la saisie terminée le tous sera validé.

Re ; en analysant bien mon problème et en pensant a haute voie :

1. je doit crée genre de table virtuelle pour stocké les données.
2. lancer un programme pour les enregistrés.

ici on doit faire appel a des triggers.
est ce que c'est la bonne solution ?
si oui une aide serrai souhaitable. merci

Bonjour,

Citation:

---

Envoyé par redoran

si l'utilisateur a un seul enregistrement de 10 champs il le valide sinon s'il a n enregistrements donc il doit validé n fois une prés une.
afin d'éviter les n appels , je cherche une methode afin d'optimisé l'enregistrement (genre panier) une fois la saisie terminée le tous sera validé.

---

Je pense que tu es en train de pondre une usine à gaz.
Faire valider individuellement (n fois) les enregistrements les uns après les autres est bancal, tu devrais repenser ta méthode.

Salam ;
Marc301:

Citation:

---

Comment sont effectuées les connexions à la base de données ?

---

est ce que je doit faire un fichier connexion par utilisateur ou tous simplement un seul fichier cbd.inc.php suffit pour tous les utilisateurs ?
rawrsc:
selon votre réflexion , je dois resté sur le principe de validation enregistrement après enregistrement avec réactualisation de la page. !!!
tous ça en utilisant les requêtes préparées vue leurs rapidités.
s'il y'a d'autres solutions je suis preneur. merci

Bonjour,

Je crois qu'on pédale dans le vide.
Pourquoi, tu ferais appel à la base de données tant que l'enregistrment n'est pas complet ou valide ?
A vrai dire, je ne comprend pas trop tes explications ni ton problème.
Comment tu peux dire :

Citation:

---

si l'utilisateur a un seul enregistrement de 10 champs il le valide sinon s'il a n enregistrements donc il doit validé n fois une prés une.

---

ça n'a pas de sens. Un enregistrment c'est un enregistrement. Ton formulaire soumet un enregistrement et c'est tout. Soit il est valide soit il ne l'est pas et tant qu'il n'est pas valide, pas d'appel à la base de données. C'est limpide, non ?

Je pense qu'il faudrait que tu postes ta problématique réelle dans son contexte parce que je pense que tu vois un problème là où il n'y en a pas.

Re , rawsrc:
peut étre que je me suis mal exprimé.
exemple:
l'utilisateur a un tableau en papier A4 formé de 10 colonnes et le nombre lignes est en fonction du nombre de département.
j'ai réalisé un formulaire de 10 colonnes et une lignes.
si un utilisateur a un tableau de 10 colonnes et de 5 lignes soit 05 départements , il doit saisir les données du premier département ( 1 ere lignes) ensuite enregistre les données dans la BDD , ainsi de suite pour les autres départements jusqu’à la fin.
mon problème:
est ce que y'a une possibilité de collecté les 05 lignes sur la machine client ensuite envoyé le tous sur le serveur?
est ce que c'est la bonne méthode?

Citation:

---

Envoyé par redoran

est ce que y'a une possibilité de collecté les 05 lignes sur la machine client ensuite envoyé le tous sur le serveur?

---

Oui, il est possible de le faire en une seule passe.
Il suffit de regrouper tes lignes de saisies dans un seul formulaire et pour chaque attribut name tu mets pour valeur un tableau, comme ça :

Code:

---

1 2 3 4 5

<form action="" method="post"> <input type="text" name="dpt[0]" value="aaa" /> <input type="text" name="dpt[1]" value="bbb" /> <input type="submit" value="Envoyer"> </form>

---

ou (équivalent) :

Code:

---

1 2 3 4 5

<form action="" method="post"> <input type="text" name="dpt[]" value="aaa" /> <input type="text" name="dpt[]" value="bbb" /> <input type="submit" value="Envoyer"> </form>

---

A la soumission, tu auras dans ton tableau $_POST ceci :

Code:

---

1 2	$_POST['dpt'][0] = 'aaa'; $_POST['dpt'][1] = 'bbb';

---

En une seule soumission, tu récupères toutes tes valeurs.

Re ; moi je pensé surtout du coté crée un tableau ensuite stocker les valeurs ajouté par l'utilisateur exemple les données des 5 ou N départements ce qui me donne N lignes, ensuite faire une requête multiple d'insertion en parcourant le tableau. sa reste de la théorie mais en pratique je ne sait pas se qu'elle vaut.

pour ton exemple j'ai pas bien saisie l'idée de mettre un tableau dans le name

Code:

---

<input type="text" name="dpt[0]" value="aaa" />

---

ou plutôt comment affecté les valeurs:
exemple:
département 1:champs 1= 20 || champs2=25||......champs10=13 ==> c'est une ligne= 1 enregistrement.
action utilisateur : clique sur le bouton valider.
$_POSTchamp1='20'||$_POSTchamp2='25'||......$_POSTchamp10='13'

département 2:champs 1= 00 || champs2=05||......champs10=00 ==> c'est une ligne= 2 enregistrement.
action utilisateur : clique sur le bouton valider.
$_POSTchamp1='00'||$_POSTchamp2='05'||......$_POSTchamp10='03'

comment stocké les données ( $_POSTchamp1='20' , $_POSTchamp1='00' ) des deux départements dans le name="dpt[0]"

Citation:

---

Envoyé par rawsrc

Je pense qu'il faudrait que tu postes ta problématique réelle dans son contexte parce que je pense que tu vois un problème là où il n'y en a pas.

---

Je plussoie.

Séb :

Citation:

---

Je plussoie.

---

c'est un avis sur 117 consultations du post soit 2 % en arrondi :aie:
l'essentiel l'idée est là peut être prochainement j'arriverai a une résolution et je posterai le résultat
merci a vous. :ccool:

je plussoie l'avis de Seb. qui lui-meme plussoit l'avis de rawsrc :mrgreen: (pas sur pour l'orthographe des plussoiements par contre hahaha)

j'ai lu la discussion et j'ai pas tout compris.
j'ai cependant compris que tes colonnes te tiennent a coeur.

Citation:

---

j'ai un formulaire de 10 champs= ( donc un (01) enregistrement).
l'utilisateur valide le formulaire en moyenne trois (03) fois soit trois enregistrement l'un après l'autre.
l'application doit géré une moyenne de 500 utilisateur.
donc 500*3*10 !!!!!

---

faux => tu as 500 * 3 enregistrements.
tu peux avoir 5 ou 150 colonnes a remplir, au final, ca sera un seul enregistrement.

meme si mysql pourrait aisement gerer 500 * 3 enregistrements / jour, tu peux stoquer les requetes de chaque utilisateur dans une session, et l'executer quand il a fini.

exemple :
il renseigne un formulaire, et clique sur enregistrer => hop, la requete sql generee dans une variable de session..
il fait 1 ou 2 ou plus autre enregistrements, a chaque fois ca ajoute une requete sql dans une variable de session (mais concretement, ca ne fait rien a la base de donnees)

quand il en est a 3 requetes pretes, tu peux forcer l'execution de ces requetes pour concretement le inserer toutes d'un coup.
ou alors proposer un bouton "enregistrer concretement le travail en cours"

seul hic, s'il ferme le navigateur alors qu'il y avait n requetes en stand-by.

=> c'est une autre idee d'approche

Salam ;après avoir constaté le travail de l'utilisateur c'est a dire sont besoin réel , il a eu lieu de ce qui suit:
l'utilisateur poste le formulaire avec des champs renseignés.
l'utilisateur lit l'enregistrement une fois affiché après la validation.
en matière d'optimisation:
les requêtes préparées génère un gain de temps.
en ajoutant la panoplie des transactions , triggers et procédures stockés sa ne fait que du bonheur... :ccool:

De ce que j'ai compris de ta problématique, voilà un algorithme qui devrait convenir.

1) 1 formulaire avec au départ 1 ligne de X colonnes.

2) L'utilisateur saisit les informations dans la ligne existante.

3a) Soit il a fini et valide sa saisie
=> aller vers 4)
3b) Soit il n'a pas fini et clique sur un bouton pour ajouter une ligne au formulaire.
=> retour vers 2)

4) Enregistrement en base de données de toutes les lignes saisies en une seule requête (si elle ne concerne qu'une seule table) du type :

Code:

---

1 2 3 4

INSERT INTO la_table (les_colonnes_a_alimenter) VALUES ('les_valeurs_de_la_premiere_ligne'), ('les_valeurs_de_la_deuxieme_ligne_eventuelle'), ('les_valeurs_de_la_nième_ligne_eventuelle')

---

Il faut juste prévoir, lors de l'ajout d'une ligne au formulaire, d'enregistrer dans un tableau les données qui viennent d'être saisies et de mettre ce tableau en session afin de ne pas perdre les données et être capable de les réafficher dans le formulaire en cas de pépin.

L'ajout de la ligne au formulaire peut se faire en Ajax ou par réactualisation de la page.

une requête préparé serai mieux

Salam ; exactement Cinephil , je simulé le fonctionnement de phpMyadmin lors de la création des colonnes d'une tables.
dans mon cas c'est la création des lignes dans une variable tableau afin d’enregistrés les données ensuite valider le tout.
stealth35 ton point de vue me conforte , donc des requêtes préparées couplées aux transactions.
s'il y'a un autre avis le débat est ouvert alors n’hésitez pas vous ête en plein chantier :massacre:

Ma méthode n'empêche pas la requête préparée je pense.

4) Préparation de la requête et envoi au SGBD

5) Envoi du paquet de données à la requête préparée.

Mais je n'ai pas l'impression que ce soit plus rapide dans ce cas.

Citation:

---

Envoyé par redoran

stealth35 ton point de vue me conforte , donc des requêtes préparées couplées aux transactions.
s'il y'a un autre avis le débat est ouvert alors n’hésitez pas vous ête en plein chantier :massacre:

---

pas besoin de transaction, ton formulaire doit retourner que les valeurs sous forme de tableau comme, ensuite 1 ligne ou 1000 lignes ne changera rien, ensuite t'auras juste a bouclé sur sur ton execute

Stealth35 :

Citation:

---

pas besoin de transaction

---

selon vous les requêtes préparées feront l'affaire.
les transaction assure l’intégrité des requêtes en assurant leurs exécution c.a.d.l'exécution complète de l'opération ou pas.
donc je crois pas que les requêtes préparées remplace cette action.

Citation:

---

Envoyé par redoran

Stealth35 : selon vous les requêtes préparées feront l'affaire.
les transaction assure l’intégrité des requêtes en assurant leurs exécution c.a.d.l'exécution complète de l'opération ou pas.
donc je crois pas que les requêtes préparées remplace cette action.

---

tu sais comment fonctionne une requête préparée ?

Citation:

---

Envoyé par redoran

Stealth35 : selon vous les requêtes préparées feront l'affaire.
les transaction assure l’intégrité des requêtes en assurant leurs exécution c.a.d.l'exécution complète de l'opération ou pas.
donc je crois pas que les requêtes préparées remplace cette action.

---

Les requêtes préparées servent surtout à gagner en perfs. La requête n'étant compilée qu'une fois et le plan d'exec calculé une fois aussi.

L'interêt des transactions c'est de pouvoir faire un rollback sur tout ton traitement si ça pête au milieu et donc d'assurer l'intégrité des données.

Le but de ces 2 fonctionnalités n'est pas du tout le même.
On peux d'ailleurs les cumuler.