Architecture d'un comparateur de prix [Résolu]

[dragohn]

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

[kivan666]

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.

[_Mac_]

Mon avis :

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...

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

[dragohn]

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