IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Conception Web Discussion :

Architecture d'un comparateur de prix


Sujet :

Conception Web

  1. #1
    Membre régulier Avatar de dragohn
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Août 2006
    Messages
    85
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2006
    Messages : 85
    Points : 124
    Points
    124
    Par défaut Architecture d'un comparateur de prix
    Bonjour,

    J’ai fait une recherche avant de poster, sans trouver de réponse.
    Si je ne suis pas dans la bonne section, toutes mes excuses, je pensais qu’elle convenait le mieux.

    Je cherche des renseignements sur les comparateurs de prix, non pas sur comment récupérer les prix (j’ai cherché et trouvé), mais d’un point de vue architecture/organisation. Je me pose 2 questions :
    1. Dans un comparateur de prix, les fiches produits (infos sur les produits, caractéristiques), sont elles entrées ‘à la main’ (et donc besoin de pas mal de personnel pour enregistrer un bon catalogue), ou traitent-ils cela de façon automatisée ? Si de façon automatisée, comment ??
    2. Toujours dans le cas du stockage du catalogue, ce stockage se fait il dans une base de données où chaque type de produit dispose de sa propre table (comportant ses propriétés particulières), ou les infos du produit sont elles stockées hors base de données, par exemple dans un des fichiers XML, la base de données ne stockant alors uniquement que pour 1 produit son nom, le type de produit, et le fichier XML associé ?


    Voilà. Je ne recherche pas des réponses toutes faites, mais plutôt à comprendre le système et sa conception. Le but pour moi n’est pas de concevoir le nouveau comparateur ultime (lol), mais simplement de comprendre et de m’en faire un petit pour mon site, mais qui soit défini le plus proprement possible.
    Si vous avez des infos, ou simplement des conseils, ou des avis sur la question, n’hésitez pas.

    Merci beaucoup.

    Cyril

  2. #2
    Membre habitué Avatar de kivan666
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    242
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 242
    Points : 177
    Points
    177
    Par défaut
    Ta question est un peu vague... tout cela relève des choix techniques tous discutables...
    Mais d'une manière gnérale il me semble nécessaire qu'à un moment donné qq'un rentre les prix à la main sauf si tu les récupère par exemple chez Amazon qui propose un webservice pour... maintenant évidement tout dépend ce que tu veux faire...

    Ensuite pour la gestion du catalogue je pencherai pour une base de donnée, plus souple et modulable que uniquement des fichiers XML.

  3. #3
    Rédacteur
    Avatar de _Mac_
    Profil pro
    Inscrit en
    Août 2005
    Messages
    9 601
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 9 601
    Points : 12 977
    Points
    12 977
    Par défaut
    Mon avis :

    Citation Envoyé par dragohn
    Dans un comparateur de prix, les fiches produits (infos sur les produits, caractéristiques), sont elles entrées ‘à la main’ (et donc besoin de pas mal de personnel pour enregistrer un bon catalogue), ou traitent-ils cela de façon automatisée ? Si de façon automatisée, comment ??
    Si tu sais comment récupérer les prix, tu dois savoir comment récupérer les références, non ? Pose-toi d'abord la question de savoir comment retrouver le bon produit concerné par un prix (i.e. tu récupères un prix, comment tu sais à quel produit de ta base de données l'attribuer ?). Demande-toi également quelles infos des produits tu veux récupérer. Si c'est simplement un nom, une référence et une photo, ça doit être assez facile de récupérer ces infos avec le prix, non ?

    Pour récupérer ces données, à mon avis que 2 solutions possibles :
    1. Acheter des bases de données existantes
    2. "Crawler" un site comme Amazon avec un robot

    A mon avis, la saisie manuelle, oublie. Faisons un calcul simple "optimiste" : en combien de temps estimes-tu qu'un bon mec qui saisit peut rentrer une référence ? Disons 1 minute. Combien de références veux-tu ? Disons 100.000 pour commencer (ce qui me semble peu au regard des concurrents). Dans ce cas, la saisie complète sans erreur donne 1 x 100.000 = 100.000 minutes = 1667 heures = 208 jours travaillés = 1 an travaillé temps plein pour 1 personne...

    Citation Envoyé par dragohn
    Toujours dans le cas du stockage du catalogue, ce stockage se fait il dans une base de données où chaque type de produit dispose de sa propre table (comportant ses propriétés particulières), ou les infos du produit sont elles stockées hors base de données, par exemple dans un des fichiers XML, la base de données ne stockant alors uniquement que pour 1 produit son nom, le type de produit, et le fichier XML associé ?
    Pour des raisons de performance, d'interfaçage, de requêtage et de modélisation, je dis base de données sans hésiter. Je ne pense pas qu'un ou plusieurs fichiers XML de plusieurs Go soit une bonne solution... Après, s'il y a une table pour chaque type, etc., c'est une question de modélisation. On ne peut pas répondre comme ça, cash. Et la modélisation, c'est en grande partie le secret du comparateur de prix. Garde en tête l'objectif : pouvoir comparer les prix. Il y a donc 2 impératifs :
    1. Pouvoir retrouver très rapidement une référence à partir de qq éléments éventuellement mal orthographiés
    2. Pouvoir retrouver tous les prix de cette référence

    A mon sens, une jolie base qui modélise parfaitement un produit, ce n'est pas forcément ce qui te permettra de répondre rapidement à ces 2 impératifs. Par ailleurs, certains SGBD proposent des techniques d'optimisation différentes (partitionnement des tables, index bitmap, etc.). Ce n'est pas une chose facile à décider en 2 minutes

    Du détail, du détail, du détail !!!
    Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute

  4. #4
    Membre régulier Avatar de dragohn
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Août 2006
    Messages
    85
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2006
    Messages : 85
    Points : 124
    Points
    124
    Par défaut
    Merci beaucoup !
    Je cherchais principalement des avis sur ‘comment aborder le problème’, et merci d’y avoir répondu Je mets d’ailleurs de ce pas le tag ‘Résolu’.
    En ce qui concerne le stockage via du XML, en effet, cela ne répond pas au mieux à ce que je souhaite faire, et la base de données est donc la plus logique des solutions. Votre avis me conforte dans mon idée.

    Kivan666 => pour rentrer les prix, je me tâte encore sur la méthode (pour le moment j’étudie les façons de faire). Je ne connais pas le webservice d’Amazon (il faut avoir rapidement un statut particulier pour l’utiliser si j’ai bien compris), et je me penche d’abord sur le système d’Alapage. Pour le moment, je songe à stocker pour chaque produit, son ID dans le catalogue d’une boutique en ligne, pour ensuite récupérer le prix. C’est la méthode que je creuse actuellement, mais je ne dis pas que c’est la bonne.

    _Mac_ => En effet, je n’avais pas fait le calcul pour l’enregistrement manuel, et ça fait peur ! lol, merci ! Je ne savais pas qu’il était possible d’acheter des bases de données de produits.
    En effet, pour de l’insertion massif, ‘crawler’ un site de vente semble une bonne idée, peut être à creuser pour évoluer par la suite.

    En fait, je ne cherche pas à stocker 2-3 millions de produits, mais pour le moment cibler des catégories de produits précises (par exemple ‘juste’ les jeux vidéo et les livres informatiques par exemple).

    Au final, mon objectif est de créer un petit comparateur de prix fonctionnel, et qui permet de montrer que je sais faire des choses (pour un développeur, ça fait toujours mieux d’avoir des choses à montrer). Après si mon comparateur est fait proprement, il est possible que je le fasse croitre, mais l’objectif n’est pas de concurrencer les grands du domaine à moi tout seul.

    Encore merci pour vos avis.
    Bonne journée

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Developpement d'un site comparateur de prix
    Par juxrei dans le forum Débuter
    Réponses: 1
    Dernier message: 01/12/2009, 18h03
  2. Développer un comparateur de prix type TWENGA
    Par fraginfo dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 3
    Dernier message: 26/04/2009, 00h50
  3. comparateur de prix sous access
    Par mkl159 dans le forum Requêtes et SQL.
    Réponses: 3
    Dernier message: 07/04/2008, 03h57
  4. Les comparateur de prix, comment fonctionnent t'il ?
    Par Death83 dans le forum Services
    Réponses: 7
    Dernier message: 25/08/2006, 15h06
  5. Fonctionnement des comparateurs de prix ?
    Par masseur dans le forum Services
    Réponses: 3
    Dernier message: 22/01/2006, 21h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo