[Conception] Modif différée ou utilisation différée d'une donnée dans une table

[Adrien93]

Bonjour,

Je retourne depuis quelques heures le problème dans tous les sens, mais je ne voie pas comment réaliser ce qu'il me faut.

J'utilise une table dans laquelle, entre autre, on trouve des tarifs. L'idée étant d'avoir une page de modification (que j'ai en partie) avec un champ dans lequel on précise la date à laquelle les modifications doivent être prises en compte.

Ca me paraît pas très évident à faire. Par exemple le 30 octobre 2006 un tarif est modifé et prend effet le 10 Novembre. Il ne faudra pas qu'en utilisant la table via un site, on voit le nouveau tarif avant le 10 Novembre.

Une idée ?

[papyphp]

Bonjour,

Tu pourrais :
créer un table des modifs qui contient l'id de l'enregistrement à modifier, la date de modification et la modification à effectuer.
Tu enregistres dans cette table les modifications de tarif
tu crées une tâche cron qui tout les matins va balayer cette table, faire les modifs du jour et effacer l'enregistrement de la table des modifs

ou alors

modifier la table des tarifs en ajoutant deux colonnes : nouveau_tarif, a_partir_du
créer une tâche cron qui balaie la table tout les matin et qui fait les mises à jour

il y a certainement d'autres moyens.

A+

[Adrien93]

Merci pour ta réponse.

J'avais également songé à un spooler, un peu comme une imprimante, avec un fichier des requêtes à faire, ou juste des données à modifier et puis un cron.

Si quelqu'un a d'autres idées.

[francis m]

même sans cron, tu peux le faire : tu crées une table des tarifs, comprenant les champs id_produit, tarif, a_partir_de

la page de modifications rajoute simplement une ligne

le désavantage, c'est que ta table peut rapidement augmenter si tu changes souvent tes tarifs.
l'avantage, c'est que tu mémorises les tarifs antérieurs, tu gardes un historique complet.

cela t'obligera peut-être d'avoir deux tables : celle décrite précédemment, et celle contenant toutes les caractéristiques du produit, et comprenant également le champ id_produit.

Avec les jointures, la recherche restera rapide (pour plus de détails sur les jointures, voir par exemple ftp://ftp2.developpez.be/developps/php/mysql.pdf

[Adrien93]

Oui effectivement ça pourrait être une solution, mais je pense que ça me compliquerait la tâche pour développer le front-end d'administration de la table, en rajoutant notamment des contrôles sur la date pour ne pas afficher les historiques lors de l'édition par exemple.

[francis m]

je n'ai pas creusé la question

et effectivement, il est peut-être difficile de faire des conditions dans ta requêtes prenant la totalité de tes produits et uniquement la dernière date valable.

si ce n'est pas possible, tu peux rajouter un champ jusqu_a dans la table des tarifs. dans ton formulaire d'enregistrement des tarifs, tu peux remplir ce champ lorsque tu crées un nouveau tarif

une autre possibilité est de faire ta requete avec jointure avec un where sur la date du jour, comprenant ainsi tout l'historique mais pas le futur, et lors de l'édition, tu ne prends en compte que le dernier tarif.

cela ne doit pas être bien compliqué.

[vg33]

Je vote pour la solution de francis m, qui me semble la plus simple et la plus "atomique"
Tu peux aussi supprimer l'ancien tarif la première fois que tu utilises le nouveau, ou le déplacer dans une table 'archives'. Il ne te reste alors que 2 tarifs maximum dans la même table principale. Tu dois t'en sortir avec un simple "WHERE date_validite > NOW()".

[Adrien93]

En effet dans le fonctionnement ça me paraît plus simple globalement. Je vais me pencher sur cette solution.

Je n'ai pas recensé le besoin d'historioriser les tarifs. Donc en effet, il va falloir que je regarde la manière de supprimer l'ancien enregistrement à la première utilisation du nouveau, ce qui ne doit pas être très sorcier.

Merci à vous

[Adrien93]

Bon en y travaillant, j'ai découvert un cas possible et facheux.

Supposons que j'ai deux ou trois ou quatre ... modifications tarifaires pour un même produit.

Si je sélectionne le tarif dont la date_validite > NOW() j'aurais plus d'un résultat, sachant que je peux pas prévoir la durée de validité d'un tarif à l'avance, je n'ai pas prévu ce champ.

Ainsi pour l'édition des tarifs je n'affiche que ceux qui sont < NOW(). Du coups j'enlève bien les tarifs du futur.

Je but maintenant sur ce nouveau problème. J'avais bien pensé à soustraire NOW() aux autres dates trouvées et prendre le tarif où la différence est la plus petite. Mais ça me paraît un peu usine à gaz à développer.

Peut-être avec le recul auriez-vous une vision plus éclaircie sur ce problème ?

Merci

[vg33]

C'est ce que je te suggérais dans mon précédent post.
A la première utilisation d'un tarif, tu supprimes le précédent. Le problème ne se pose donc plus, car tu n'as toujours qu'un seul tarif valable en bdd.
Autre possibilité : tu as une table tarifs_futurs. En début de journée (tâche cron ou à la première requête), tu bascules les tarifs devenus valables vers la table principale. Ainsi, à part une fois par jour, les requêtes se font sur une seule table avec un seul tarif par id => ultra rapide.

[Adrien93]

C'est ce que je te suggérais dans mon précédent post.
A la première utilisation d'un tarif, tu supprimes le précédent. Le problème ne se pose donc plus, car tu n'as toujours qu'un seul tarif valable en bdd.

Bah non justement :s Si toutefois deux ou trois tarifs futurs sont saisis, ça ne colle plus. Ca m'a déprimé en le découvrant lol.

Autre possibilité : tu as une table tarifs_futurs. En début de journée (tâche cron ou à la première requête), tu bascules les tarifs devenus valables vers la table principale. Ainsi, à part une fois par jour, les requêtes se font sur une seule table avec un seul tarif par id => ultra rapide.

On en reviendrait quasiment à mon idée initiale d'une sorte de spooler avec un client qui irait scanner la base et voir s'il faut basculer ou non sur les nouveaux tarifs. Grrrr ça m'ennui j'ai développé toute la journée autour de l'idée précédente.

[vg33]

Je pense que tu devrais t'en sortir avec une combinaison de MAX() et <= NOW(), ou DISTINCT + <= NOW() + ORDER BY date.

[Adrien93]

Pas bête !

Merci, je vais me pencher là dessus.

[Adrien93]

Voici finalement la requête qui me permet de récupérer précisément le bon tarif :

SELECT *
FROM `X`
WHERE prefix = '01'
AND date_validite = (
SELECT MAX( date_validite )
FROM X
WHERE prefix = '01'
AND date_validite <= NOW( ) )

Cependant, pour m'éviter de faire une requête par préfixe concerné et surcharger la base, je fais UNE requête qui récupère tout et je travail ensuite sur une variable tableau, beaucoup plus rapide à manipuler.

J'ai donc, tout naturellement adapter la requête ci-dessus comme suit :

SELECT *
FROM `X`
WHERE date_validite = (
SELECT MAX( date_validite )
FROM X
WHERE date_validite <= NOW())

Sauf que là je me heurte à un problème. Quand le tarif a une date de validité à NOW(), il apparaît bien en résultat. Parcontre dès lors que je le supprime et que normalement c'est le tarif précédent qui devrait être affiché, et bien la requête me renvoi rien. Enfin tout daté à NOW(), rien pour le futur donc ça c'est OK, mais en dépit de date_validite = NOW() visiblement j'ai pas le tarif d'avant.

Je ne comprend pas.

[Adrien93]

Ah bien oui c'est normal puisqu'en fait la requête imbriquée me renvoi la date_validite <= à aujourd'hui. Etant donné que les autres lignes sont initialisées à aujourd'hui, il zappe les date_validite d'avant.

C'est ennuyeux. Je continue à me creuser la tête sur la requête, si quelqu'un a une idée