[phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2342: file_get_contents(http://www.like-rank.com/profile.php?id=eyIwIjoiRm9ydFRyYWZpYyIsIjEiOiJGb3J0VHJhZmljIiwiMiI6InBwcHBsdXMiLCIzIjoiRm9ydFRyYWZpYyIsIjQiOiJBcm1lbiIsIjUiOiJGb3J0VHJhZmljIiwiNiI6IkFybWVuIiwiNyI6IkZvcnRUcmFmaWMiLCI4IjoiQXJtZW4iLCI5IjoiRm9ydFRyYWZpYyJ9): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found
MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée

Vous aimez ? Like-Rankez ;) Like-Rank


MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée

le Jeu 8 Mai 2014 14:50

Bonjour, c'est la première fois que j'essaye de faire une chose comme ça, donc je me demande quelle est la façon de faire que les pros utilisent déjà.

Ce que je veux faire c'est suivre l'évolution des propriétés d'une entitée quelconque au fil du temps.

Prenons un exemple concret :

On a un catalogue produits, chaque produit a un nom, une description, un prix, et d'autres propriétés.

J'aimerai donc faire un programme qui suive l'évolution des propriétés de chaque produit. Sans jamais toucher au catalogue bien sûr. Simplement en vérifiant chaque jour chaque produit pour voir si une des propriétés à changé, et si oui, en garder une trace. C'est à dire ne rien perdre des modifications. Exemple :

Un jour, un produit change de prix, un autre a son nom modifié :
- je veux garder en mémoire dans une base mysql, l'ancien prix, et le nouveau prix, avec la date du changement du prix. Pareil pour le nom de l'autre produit.

Donc, en ayant des milliers de produits, comment faire pour ne pas avoir une base de données qui grossissent trop vite?
Si à chaque fois qu'il y a un changement, j'enregistre une nouvelle entrée avec toutes les propriétés du produit, la taille de la base de données risque de vite grimper...

Comment est-ce que les pros gèrent ce problème? Est-ce qu'il font une table par propriété par exemple, avec une table produit réduite au minimum (id produit) au lieu d'une table pour les produits avec chaque propriété dans des champs?

J'espère vraiment m'être fait comprendre et que vous pourrez m'aider, m'indiquer des resources ou me donner des pistes, car je sais que ce n'est pas facile d'aider avec seulement de la théorie, sans exemple réel.

Merci.





FortTrafic





le Jeu 8 Mai 2014 18:47     Re : MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée      

En fait je ne pense pas que je veux suivre toutes les propriétés d'un produit, style les changements de nom ou de description, ce n'est pas important..
Ca serait plutôt pour suivre le prix, le nombre de ventes, des choses comme ça.

Je me demande s'il ne faudrait pas que j'ai une structure dans le style :

Table produit avec les champs pour toutes les proprietes
id
propriete1
propriete2
propriete3
...

Table propriete qui contiendra 2 ou 3 proprietes que je veux suivre
id
nom

Table produit_propriete pour faire le lien entre les deux premieres tables

Et donc ca serait cette derniere table qui contiendrait toutes les modifications (elle va grossir vite) j'aurai comme champ :
Table produit_propriete
id
produit_id
propriete_id
valeur
date

Et quand je detecte un changement d'une des proprietes que je veux suivre, je l'enregistre dans cette table, et ensuite je met a jour l'entrée complete dans la table produit.

Est-ce que ca vous parait ok?





FortTrafic



le Jeu 8 Mai 2014 20:56     Re : MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée      

Regarde comment wordpress fait pour les posts.

Il garde tous les posts sauvegardés, ce qui permet de remonter en arrière.



Merci de : FortTrafic



pppplus


le Jeu 8 Mai 2014 21:16     Re : MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée      

Bonjour, merci, c'est vrai que je ne connais pas du tout wordpress, mais drupal a un tel systeme de revision..

Mais j'ai l'impression que c'est autre chose car il va y avoir des milliers de produits, et a force de petits changements, ca va vite faire beaucoup d'entrées.

Sur WRI on m'a conseillé de faire que 2 tables, une pour le produit + les proprietes que je ne souhaite pas suivre et une pour les proprietes variables, en melangeant tous les types et en ayant l'id du produit, donc :

Table produit
id_produit
propriete1
...

Table propriete
id_propriete
id_produit
type
valeur
date

(en fin on m'a conseillé date_debut et date_fin comme champs, mais je ne suis pas sur que ca soit utile)

Qu'est-ce que t'en penses, la table propriete va grossir assez vite avec plusieurs milliers de produits et chacun ayant des changements de temps en temps..
Je me dis bien sur que ce n'est pas la peine de m'en inquiéter maintenant, que le temps que ca devienne un problème il se sera passé facilement plusieurs mois voir plus d'un an, je ne sais pas en fait.. Je ne sais même pas comment calculer a partir de combien d'entrées ca va etre un probleme..

Mais c'est vrai qu'avec deux tables les requetes seront un peu plus simples, sans doute qu'il n'y a pas besoin de faire une table de liaison entre la table produit et propriete..

Si je fais une erreur de conception maintenant, j'espère que c'est rattrapable dans tous les cas plus tard..

Je pense que je vais commencer comme ça, avec deux tables seulement.. Vu que c'est la première fois que je tente un truc comme ça avec un script qui va surveiller tous les jours tous les produits, je vais avoir bien d'autres soucis, donc il ne faut pas trop que je perde d'énergie uniquement en théorie avec la base de données.. :-)

Merci de ta suggestion.





FortTrafic



le Jeu 8 Mai 2014 21:26     Re : MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée      

Oui, mais tu peux encore optimiser, je m'explique lorsque l'on doit conserver une log, puisque en fait c'est ce que tu veux faire.
On modèlise au plus juste. Ainsi même si toutes tes popriétés n'ont pas la même structure, tu ne gardes qu'un champ pour tes différentes propriétés mais ce champ a une structure texte qui te permet de stocker ce que tu veux dedans. Ainsi ta table produit va avoir un champ nouvelle propriété, l'ancienne et le nom du champ qui a changé, l'id produit ainsi que la date et le user qui a effectué la modification. Après il faut mettre les bons index, et là tu as une log totalement optimisée. Toutes les gestions de log sont construites suivant ce modèle.

Ainsi cette table va grossir vite certes, mais elle sera totalement optimisée. Ensuite pour de très grosses tables, tu construis tes requêtes avec des procédures stockées, ce qui te fait gagner la compilation des select lors des appels. Voila comment un ancien pro ferait. Bon je te donne les grandes lignes.



Merci de : FortTrafic



Armen


le Ven 9 Mai 2014 08:37     Re : MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée      

Merci Armen, mais je t'avoue qu'il doit me manquer des neurones ou bien de l'expérience, parce que je n'arrive pas à comprendre ton message, il me manque plusieurs bouts..

Ce que je vais faire, c'est commencer, me lancer, et puis je pense qu'ensuite quand je serai bien dedans, que j'aurai galéré pour certains trucs et lu des choses en ligne pour les résoudre, je serai plus capable de comprendre..
Il me manque l'imagination, vu que je ne maîtrise pas le sujet, j'ai du mal à me faire une idée du sens des mots, des phrases, etc..
J'y arrive mieux sur des sujets que je connais bien, mais là je ressent sans doute l'effet que doivent faire certaines de mes réponses à des débutants en informatique, ou html/php en général.. :-)
Ce n'est pas agréable, du tout.. Car en relisant plusieurs fois, doucement, je n'arrive toujours pas à former une image mentale de ce que tu veux dire, c'est un peu frustrant j'avoue car ce que tu me dis aurai surement pu me servir mais bon voilà..

Donc je me lance aujourd'hui, et après j'aurai une meilleure vision des problèmes éventuels et je pourrais poser des questions plus précises.

Merci et A+





FortTrafic



le Ven 9 Mai 2014 14:59     Re : MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée      

Bonjour,

tu n'as pas à t'excuser, si tu n'as pas compris, c'est que je me suis mal exprimé. En relisant mes propos, je suis en train de me dire que c'était assez obscur. ;)

Si j'ai bien compris, tu as une table produit avec x propriétés, mais si j'ai bien compris également tu ne souhaites pas forcément suivre toutes les propriétés. La modélisation que l'on t'a soumise , je ne la comprends pas trop tel quel l'est. Mais si le nombre des propriétés suivies est minimal, je pense que tu peux encore optimiser en modélisant avec une seule table. Prenons un exemple,

Table produit
id_produit
propriété1
propriété2

propriété100


admettons que tu ne suives que 20 propriétés, je te propose comme optimisation de faire une seule table de suivi ainsi :

log_produit

id bigint en autoincrement.
id_produit
nom_propriété contient le nom du champ de la vrai table produit
new_valeur nouvelle valeur du champ
ancienne_valeur valeur avant changement, important car si beaucoup de changement tu as le
suivi complet des différentes valeurs.
type_champ typologie du champ : booléen, texte, décimal ….
date_changement date

L'idée d'optimisation est de gérer qu'un seule table où dans nom_propriété tu auras des noms de champs différents. En effet sans préjuger de la modélisation de tes données, tu auras des propriétés avec des types différents : décimales, textes, booléen....
ton champ type_champ t'indiquera le type de champ de la table produit : booléen, texte, décimal....
type de champ peut être optimisé avec une valeur de 1 caractères maxi, cette valeur peut servir si tu souhaites savoir quel type de champ tu as pour effectuer des calculs ou autre, pas forcément nécessaire.

Chaque ligne contiendra l'id de la la ligne, id produit, le nom de la propriété, l'ancienne et nouvelle valeur, un type_champ optionnel et la date.
Tu constateras, que si tu ne changes qu'une propriété d'un produit, seule une petite ligne est ajoutée. Cette table va rester petite et totalement optimiser pour tes requêtes.

En fait, ma proposition est une modélisation suivant le principe d'un Modèle Conceptuel des Données Meurisien, car si l'on souhaite modéliser proprement, on évite de mettre toutes les propriétés d'une occurrence dans une même ligne, par exemple la table produit telle que tu la présentes est une aberration, puisqu'elle contient x propriétés qui ne sont peut-être pas sûr d'être renseignées. Perte de place et ralentissement des requêtes SQL.

Voila, j'espère avoir été moins abscons.





Armen


le Ven 9 Mai 2014 15:08     Re : MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée      

Merci, jai tout compris, cest tres tres clair.
Je suis partit comme ca, une table produit avec toutes les proprietes (elles seront toutes remplies a chaque produit) et une table pour suivre certaines proprietes.
Je vais toujours mettre a jour lentree de la table produit avec les valeurs actuelles, mais jenregistrerai dans la table suivi une ente par modif.
Donc cest a peu pres pareil, sauf que je nai pas encore mis tous les champs que tu mindiques, je vais sans doute ecouter ton conseil a la lettre, meme si par exemple la date fin je narrive pas a voir pourquoi jen ai besoin puisque la date de fin cest soit la date de debut de la prochaine entree pour le couple produit-propriete, soit la date daujourdhui sil ny a pas dentree plus recente..

Merci beaucoup pour ton explication LIMPIDE !





FortTrafic



le Ven 9 Mai 2014 19:03     Re : MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée      

FortTrafic a écrit:Donc cest a peu pres pareil, sauf que je nai pas encore mis tous les champs que tu mindiques, je vais sans doute ecouter ton conseil a la lettre, meme si par exemple la date fin je narrive pas a voir pourquoi jen ai besoin puisque la date de fin cest soit la date de debut de la prochaine entree pour le couple produit-propriete, soit la date daujourdhui sil ny a pas dentree plus recente..

Merci beaucoup pour ton explication LIMPIDE !



Tu as tout à fait raison, mais moi je ne te propose pas de date_fin car dans ce que tu demandes, elle n'a aucun objet et ne sert à rien, tu l'as d'ailleurs bien expliqué ci-dessus.





Armen


le Ven 9 Mai 2014 19:14     Re : MYSQL/PHP : Suivre l'évolution des propriétés d'une entitée      

Oui j'ai confondu désolé, c'est sur un autre forum (WRI) qu'une personne qui me donne des conseils aussi insiste sur la date_fin.. Et comme j'ai lu mes deux topics dans le même temps, tout était dans ma tête encore embrouillé. D'ailleurs sur WRI je leur ai dit que je fais une pause dans mon topic, car j'arrive même pas à comprendre ce que certains disent, ça me fait un peu comme ton message d'avant.. Je relis, et non, ya rien qui se forme dans ma tête :-)
Je pense c'est simplement parce qu'ils ont l'habitude, donc me font des paragraphes en allant vite au lieu de montrer les schémas simple avec retour à la ligne :-)

Mais bon j'ai avancé la création des tables, des champs, parce qu'en fait je n'ai pas que deux tables, là je parlais juste pour simplifier, mais par exemple chaque produit est dans deux catégories, etc. Donc le fait de retravailler avec phpmyadmin, ca me revient un peu, d'ici demain soir j'irai relire leur messages et peut être ça fera tilt :-)

En tous cas j'ai hâte d'avoir fini en fait, ça va être super d'avoir mon serveur qui travaille comme une fourmillière pour aller vérifier chaque produit (je pense une vingtaine par éxecution du script) toutes les X minutes et noter chaque changement..
Plus après un mois, des graphismes sympa sur l'historique et d'autres affichages..
J'ai hâte d'en être à cette partie là d'ailleurs, les affichages des données de l'historique.
Je pense que je vais utiliser les outils de Google pour les graphs, à voir si c'est ça le mieux.





FortTrafic






Retourner vers Développement d'un site web

 


  • Articles en relation
    Réponses
    Vus
    Dernier message
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité
 


  • Information sur les posteurs
  • FortTrafic

    Habitué
    Remerciements : 50
    Avatar du membre
    216 Messages
    6 sur ce sujet
    Inscription Mai 2014
    site web
  • Armen

    Habitué
    Remerciements : 115
    Avatar du membre
    323 Messages
    3 sur ce sujet
    Inscription Mai 2012
  • pppplus

    Habitué
    Remerciements : 83
    Avatar du membre
    tickets et jeux flash dans un monde de fantômes
    322 Messages
    1 sur ce sujet
    Inscription Mar 2011

allez en bast