Discussion :

[webapi]

bonjour,

a la suite d'une refonte importante en cours, je suis entrain de refaire la modélisation
de la partie comparateur de la bdd de mon site.
au début j'avais pour gagner du temps simplement évaluer et réaliser la structure "a la main", elle avait par la suite évoluer petit a petit.
cela a été évidemment une erreur (temps de perdu, espace disque, performance lecture....), certain diront l'erreur classique...
bref j'ai donc modéliser cette fois cette partie (améliorer) de façon "rigoureuse" et je souhaite avoir des avis, critiques sur cette aspect (mcd en pj).
je n'ai pas mis les tables sans relations comme celles du filtrages et celles des autres partie.

les critères sont :

1 produit a 1 catégorie et marque et n marchands au maxi
1 produit a 1 catégorie et marque et 0 marchand au mini

(fiche technique)
1 catégorie a n propriétés et n propriétés a n valeur au maxi
1 catégorie a 0 propriétés et 0 propriétés a 0 valeur au mini

1 marque peut avoir n produits au maxi
1 marque peut avoir 0 produits au mini

1 marchand peut avoir 0 produit au mini
1 marchand peut avoir n produit au maxi

1 produit a 0 photos au mini
1 produit a n photos au maxi

1 produit a 0 histo au mini
1 produit a n histo au maxi

1 produit a 0 eval au mini
1 produit a n eval au maxi

1 produit a 0 mise en vedette au mini
1 produit a 1 mise en vedette au maxi


(données alphanumérique aléatoire en provenance des flux marchands, pas de donnée "atomique")
1 offre marchand a 1 stock , temps de livraison, frais de livraison au mini
1 offre marchand a n stock , temps de livraison, frais de livraison au maxi

1 offre marchand a 1 flux marchand pour l'import au mini et maxi

je n'ai pas mis de relation dans le mcd, je pense qu'il n'y a aucun intérêt a le faire ???
pour enregistrer un flux pour l'import pas besoin de l’enregistrer pour le maj (upload manuel par exemple) donc...

dans l'idée :
1 flux marchand pour l'import a 0 flux marchand a maj au maxi
1 flux marchand pour l'import a 1 flux marchand a maj au mini

merci par avance.

[fsmrel]

Bonjour webapi,



Vous vous étonnez du peu de retour, mas un MCD est un roman, et vous ne fournissez qu'un quart de la 4e de couverture...


Pour ceux qui ne sont pas initiés, qu’est-ce qu’un comparateur ?


Pourquoi la patte connectant l’entité-type ELEM_VEDETTE et l’association MISE_EN_VEDETTE est-elle porteuse d’une cardinalité 0,1 ?

Pour les attributs relatifs à l’EAN, en admettant qu’il s’agisse de l’EAN 13, pourquoi ne pas utiliser du CHAR(13) ?

dans l'idée :
1 flux marchand pour l'import a 0 flux marchand a maj au maxi
1 flux marchand pour l'import a 1 flux marchand a maj au mini

Mais de façon moins sibylline et elliptique ? (On n’est pas du métier...)

(données alphanumérique aléatoire en provenance des flux marchands, pas de donnée "atomique")
1 offre marchand a 1 stock , temps de livraison, frais de livraison au mini
1 offre marchand a n stock , temps de livraison, frais de livraison au maxi

Même remarque. Et quel sens précis donnez-vous au mot « atomique » ?

je n'ai pas mis de relation dans le mcd, je pense qu'il n'y a aucun intérêt à le faire ???
pour enregistrer un flux pour l'import pas besoin de l’enregistrer pour le maj (upload manuel par exemple) donc...

Ça a à voir avec l’entité-type FLUX_MARCH_MAJ ? Tout ça reste clair comme du jus de chaussettes...


Association OFFRE_MARCHAND

Êtes-vous conscient de la signification de cette association avec ses 6 pattes ? ¹
Racontez-la nous en français..

Que raconte l’entité-type obèse FLUX_MARCH_IMPORT ? Quelle est a signification précise, son rôle ?



___________________________

¹ J’en profite pour relayer l’annonce passée dans le numéro 61 de l’OS à Moelle, bien qu’elle ne soit pas de la 1re fraîcheur (juillet 1939) : « Mille-pattes cherche partenaire sérieux pour numéro de claquettes. »

[StringBuilder]

C'est moi ou "resum_eval" ne contient que :
- des données calculées
- des données en doublon

Elle n'a pas lieu d'exister. Au mieux, ce sera une vue, éventuellement stockée. Mais clairement pas une entité !

Ah, y'a aussi l'entité "histo". Pour moi, c'est la relation offre_marchand qui doit être porteuses d'une date, pas une entité qui historise dans un coin des données calculées/en doublon à partir de périodes figées et de regroupements hasardeux et figés dans le temps.

Pour le reste, j'ai pas trop fait le tour, comme dit fsmrel, c'est pas vraiment limpide, et on dirait avant tout une paraphrase de votre usine à gaz actuelle.

[webapi]

bonjour fsmrel,

merci pour ton retour, désolé pour le retard (absent hier et il y avait beaucoup a expliquer), c'est vrai que depuis 3 et demi, je suis a fond dans les comparateur de prix, je ne me rend pas compte quelque fois que ce n'est pas le cas de tous le monde, désolé de ne pas avoir plus détaillé, mais c'est vrai qu'il faudrait beaucoup de pages pour expliquer tous dans les détails.

Pour ceux qui ne sont pas initiés, qu’est-ce qu’un comparateur ?


Pourquoi la patte connectant l’entité-type ELEM_VEDETTE et l’association MISE_EN_VEDETTE est-elle porteuse d’une cardinalité 0,1 ?

Pour les attributs relatifs à l’EAN, en admettant qu’il s’agisse de l’EAN 13, pourquoi ne pas utiliser du CHAR(13) ?

a la base un comparateur de prix permet la comparaison de prix/caractéristiques de produits proposés par différents marchands et permet d'avoir des informations complémentaires comme les avis des clients.

pour la mise en avant d'un produit, il y a une erreur j'ai du oublier de corrigé les cardinalités lors de la mise en relation (d'ailleurs pas qu'ici ).

le principe c'est aucun produit ne peut être mis en avant comme x produit peuvent l'être (0,n pour l'entité produit), et un element vedette (si produit) et forcement présent dans l'entité produit MAIS je souhaite aussi mettre en avant des données de toutes autres nature , donc un élément mise en avant n'est pas forcement dans l'entité produit et un produit mise en avant est représenté q'une fois dans l’entité produit (0,1 pour l'entité elem_vedette).

pour la taille des attributs j'en ai calibré certain très grossièrement (voir très très...!) je voulais faire un contrôle/correction des attribut avant le mrd.
pour l'ean il y a 48 caractères au maxi (ean 128), pour l'upc c'est 12 chiffres et le sku une dizaine de caractère je croit, il y a aussi l'isbn que je devrait rajouter pour couvrir un maxi.

je vais passer en char() tous les attributs qui accueil plus ou moins des chaines de longueur fixe (mieux que varchar()).

Mais de façon moins sibylline et elliptique ? (On n’est pas du métier...)

l'entite flux_march_maj c'est pour enregistrer les données pour downloader les flux et l'entité
flux_march_import c'est pour les correspondance des champ du flux avec les champ des table liés
(la plupart des flux marchands ont des nom de champ différent donc obligé de faire du mappage).

la plupart du temps les flux sont maj automatiquement via http ou ftp , mais je laisse l'option de la méthode manuel, c'est a dire uploader "a la main" via ftp par ex.
donc un flux marchand a importer n'est pas obligatoirement dans l'entité flux_march_maj
et il peu y être au maximum une fois.

Même remarque. Et quel sens précis donnez-vous au mot « atomique » ?

une offre de marchand (une offre d'un marchand sur un produit) et lié au minimum et au maximum avec un stock , un temps de livraison et un frais de livraison
un stock , un temps de livraison et un frais de livraison et lié a 1 offre marchand au mini et a n offre marchand au maxi.

tous comme les quarks (briques des protons et neutrons) qui sont des particules élémentaires de la matière (jusqu'au jour ou les accélérateurs a particules permettront de trouver des éléments encore plus petit) "atomique" veut dans ce cadre "une donnée qui n'est pas divisible".
la plupart du temps dans les flux le stock et le temps de livraison et représenté par une suite alphanumérique comme '2 à 3 jours', 'plus de stock', '50 unités'.....donc des données qui pourrait être divisible.

Ça a à voir avec l’entité-type FLUX_MARCH_MAJ ? Tout ça reste clair comme du jus de chaussettes...


Association OFFRE_MARCHAND

Êtes-vous conscient de la signification de cette association avec ses 6 pattes ? ¹
Racontez-la nous en français..

Que raconte l’entité-type obèse FLUX_MARCH_IMPORT ? Quelle est a signification précise, son rôle ?

l'entité offres_marchands c'est les données (offres) des différents marchands pour les différents produits, prix, le tracking...

en faite je me rend compte que c'est pas bon, l'entité flux_march_import est effectivement obèse (sqlpro va s'énerver ), j'ai un peu bâcler la chose, il faudrait plutôt une entité avec les info de base des flux et une entité "métadonnées" avec un attribut pour les champs de destination ou les donnes issue du flux vont être stocke et un autre pour les champs source du flux la ou sont la source des donnes, le tous relié a l'entité qui contient les info des flux.

comme cela la table sera la plus petite possible (je n'utilise pratiquement jamais tous les champ)et complètement évolutive sans changer sa structure (si je souhaiter rajouter une correspondance la je suis obligé de change la structure) a votre avis ?

J’en profite pour relayer l’annonce passée dans le numéro 61 de l’OS à Moelle, bien qu’elle ne soit pas de la 1re fraîcheur (juillet 1939) : « Mille-pattes cherche partenaire sérieux pour numéro de claquettes. »

en estropiant le mille pattes l'annonce aura peut être plus de succès....



bonjour StringBuilder ,

C'est moi ou "resum_eval" ne contient que :
- des données calculées
- des données en doublon

Elle n'a pas lieu d'exister. Au mieux, ce sera une vue, éventuellement stockée. Mais clairement pas une entité !

"resum_eval" contient des données calculés et des doublons au niveau du nom de prd.
j’intègre les nom de prd au eval pour permettre en cas de purge de la table prd et des table liés pour x raisons de retrouver les produits liés au eval a la fin du nouvel import (a cause des id prd forcement différent) je sais que les eval devrait être supprime dans le cas d'une purge mais je souhaiterais les conserver.
si je mets toutes mes eval dans "detail_eval" et si je souhaite récupérer un produit avec toutes les évaluations je récupérerai autant le même produit qu'il y a d'évaluations pour celui ci(sauf si je fait une requête seul), de plus le pré-calcule économise un peu les ressources, mais c'est vrai qu'avec une vue je pourrais m'en passer...

Ah, y'a aussi l'entité "histo". Pour moi, c'est la relation offre_marchand qui doit être porteuses d'une date, pas une entité qui historise dans un coin des données calculées/en doublon à partir de périodes figées et de regroupements hasardeux et figés dans le temps.

non l'entité histo est la pour enregistré le prix mini,maxi et le nbr_march si et seulement si le prix du jour précédant est différent ou si il n'y a pas d'info a J-1 (d'ou date de fin pour mémoriser le "trou")
pour moi il n'y a aucune relation a avoir avec l'entité offre_marchands.

cela permet un MINIMUM d'enregistrement car avec x prd * y jours on arrive vite a des chiffres astronomique, c'est d'ailleurs pour cela que cette table actu est partitionné verticalement sur des tranches d'id prd et c'est très très rapide, mon algo mets a jours l'historique de 2000000 de prd en 10min .

salutations.

[webapi]

bonjour,
dans quelques jours cela fera un mois que j'ai répondu aux interrogations de fsmrel et de stringbuilder et pourtant aucune réponse a ce jour....
si vous voulez plus de précisions, explications...ou si je dit des bêtises dites le moi, en théorie c'est un forum qui permet aider, de conseiller donc....
salutations.
ps: j'ai appliquer sur le mcd les changement que j'ai mentionnés plus haut.

[fsmrel]

Bonjour webapi,


Ne nous en veuillez pas. On est au mois d'août, et j'ai besoin de souffler. Dan 8 à 10 jours je serai peut-être plus à même de revoir le sujet...


En attendant, bon courage.

[webapi]

Bonsoir fsmrel,

Pas de soucis je comprend, c'est vrai que nous sommes en août et de plus mon problème n'est pas simple, enfin si on souhaite faire correctement le design...bonne fin de vacances et a bientôt.

je vais de mon coté peaufiner/contrôler le mcd, je posterais d'ailleurs la maj.

cordialement.

[Chtulus]

Bonsoir webapi,

je vais de mon coté peaufiner/contrôler le mcd, je posterais d'ailleurs la maj.

J'allais vous posez la question

Je pense que déjà avec les infos de @fsmrel et @StringBuilder votre MCD a dû connaitre quelques différences.
N'hésitez pas à poster vos nouvelles moutures.