PHP|Débutant :: Forums

Bonjour,

Si c'était si simple (ça l'est presque^^), j'aurais presque envie de dire, que ça serait trop facile^^
En fait la méthodologie va dépendre en premier lieu du moteur base de données que vous utilisez MySQL, postGreSQL, SQLServer, un autre?
La deuxième chose à prendre en compte, est de considérer les informations à rapprocher.

Votre méthodologie sous-entend les choses suivantes:
- Que le nombre de lignes contenues dans bracoimport est toujours strictement identique à celui contenu dans la table bracobase.
- Que la seule information à mettre à jour (l'unique source de variabilité à prendre en compte) est le prix brut des articles.
- Que la colonne "art_ean" de votre table bracobase constitue la clé primaire (identifiant unique) de vos articles; qu'il en est de même pour la colonne "b_art_ean" de la table bracoimport, et enfin que chacune de ces mêmes clé primaires identifient respectivement les même articles au sens métier de votre activité.

Or, vu votre souci, je suppose qu'une au moins des affirmations ci-dessus ne correspond pas à votre cahier des charges ou à votre réalité.

A bientôt de vous lire.

EDIT: Votre code PHP, après votre requête, est, de plus, invalide car
1) votre requête ne retourne aucun enregistrement car il s'agit d'un update
2) si votre requête était un SELECT, il faudrait faire pour le moins un fetch sur votre resultset pour accéder au contenu.

Dernière modification par Jc (12-02-2014 07:49:06)

Bonjour,

Avant de répondre quant à la méthodologie, il reste à savoir encore quelques petites choses qui ont leur importance à savoir:
- Si le nb de lignes de bracoimport > nb de lignes de bracobase : Doit-on créer les articles en plus dans bracobase ? Si non quelle est la règle à appliquer?
- Si le nb de lignes de bracoimport < nb de lignes de bracobase : Doit dont supprimer les articles en trop dans bracobase ou simplement les "désactiver"? Si non, quelle(s) est/sont la règle/les règles à appliquer?
- Combien de colonnes peuvent être mises à jour? quantité variable? toujours invariante et systématique ?

++

Dernière modification par Jc (15-02-2014 11:47:18)

Bonjour,

Le gros problème avec MySQL c'est qu'aucun de ses moteurs n'est taillé pour faire de la comparaison de données du fait principalement du non support des instructions INTERSECT et EXCEPT du standard SQL qui permettent d'exclure des ensembles de données ou d'en extraire l'intersection et évite donc de faire de l'itératif, complétement contre-productif dans ce genre de tâche.

Je profite de l'occasion pour dire que c'est encore une raison qui démontre que le choix d'un SGBDR sur le seul critère de la volumétrie de données à traiter est complètement absurde.

Ceci étant dit dans votre malheur, si je puis m'exprimer ainsi c'est que vous n'avez que 3 colonnes au maximum à évaluer dans cette comparaison ce qui est une chance en soit.
Ce qu'il faut savoir maintenant, c'est si parmi ces trois colonnes vous avez une colonne de type chaîne de caractères à évaluer. L'idéal pour ce genre de comparaison est de travailler sur une collation binaire (ou pour le moins sensible à la casse) ou de travailler directement sur un type  BINARY ou VARBINARY. Le problème étant, pour ce genre de choix, de le prévoir lors de la conception, j'en conviens.
Si vous êtes sur une collation normale, faites vos comparaisons en utilisant LOWER(chaîne1)=LOWER(chaîne2)

Ensuite si les 3 colonnes concernées n'ont pas d'index, je vous conseille fortement de les indexer et pour le moins le temps de la comparaison si vous procédez par comparaison exacte, sinon laissez ces colonnes en l'état (sans index) si vous faites une mise à jour globale (méthode exposée ci-après).

Une fois ceci fait, vous réduirez considérablement les temps de traitement pour votre comparaison et ceci, d'autant plus que votre nombre de lignes à traiter est important. En moyenne vous pouvez considérer un x10 en gain de temps avec au moins une chaîne de caractères à traiter, mais cela peut être très variable, car cela dépends de beaucoup de facteurs dont nous n'avons aucun élément pour ce qui vous concerne.

Avant de faire votre comparaison je vous conseillerais ensuite de faire un pré-traitement qui consiste à l'aide de jointures à mettre à jour votre indicateur de désactivation de ligne (Cf.

)
en utilisant par exemple l'effet null sur une jointure externe à la table.

ex : UPDATE bracobase as t0 LEFT JOIN bracoimport as t1 SET t0.is_active=true WHERE t0.id=t1.id AND t2.macolonne NOT NULL
      UPDATE bracobase as t0 LEFT JOIN bracoimport as t1 SET t0.is_active=false WHERE t0.id=t1.id AND t2.macolonne IS NULL

PS: vérifiez la syntaxe car ca fait longtemps que je ne travaille plus sous MySQL et je ne suis plus certain de la syntaxe surtout pour les UPDATE, qui restent particuliers sous MySQL en terme d'écriture et de possibilités. Au pire vous serez obligé de passer par une table temporaire pour faire l'update sur bracobase ou encore une vue comme suit:

Ce préfiltrage peut donc vous éviter de faire un full scan sur quelques % de l'ensemble des enregistrement de bracobase pour la comparaison et donc vous faire gagner du temps.

Ensuite évitez d'identifier sous MySQL quelle colonne à mettre à jour surtout si chaîne à collation non binaire, et préférez une mise à jour globale surtout dans votre cas vu que vous n'avez que 3 colonnes à mettre à jour au max. Ce que je vous ai proposé précédemment va dans ce sens, et vous pourrez faire pour terminer :

Voilà, s'il y a des choses que vous ne comprenez pas, demandez

Dernière modification par Jc (25-02-2014 11:16:07)