Discussion :

[Senethril1]

Bonjour j'ai une relation particulière entre mes tables que je réutilise, dans le cas d'une table tierce créée entre deux autres , puis-je la réutiliser à la même fin ?,j'ai vraiment l'envie de construire un site ecommerce et la classification s'en trouve nettement améliorée pour l'utlisateur si j'utilise visuelement une identification claire telle que présentée par catégorie et sous-catégories.

[escartefigue]

Bonjour,

Si vous voulez des commentaires, il faut expliquer vos règles de gestion, un modèle conceptuel ou logique seul, ne suffit pas.
Par exemple sous la forme :
- Règle 01 : tout objet possède une et une seule catégorie
- Règle 02 : une catégorie peut caractériser plusieurs objets
- Règle 03 : un objet peut avoir plusieurs sous-catégories
- Règle etc...

Ce n'est pas votre question, mais votre modèle présente des erreurs :

• prix, poids, dimension ou volume en varchar c'est
• prix, poids, dimension ou volume sans unité de mesure c'est encore
• adresse sur une seule ligne en varchar(45) c'est toujours , il existe une norme postale pour les adresses
• dimension n'est pas un attribut atomique, il faut considérer la largeur, la hauteur et la longueur
• faire le lien entre un fournisseur et un stock est surprenant, vous gérez les stocks chez vos différents fournisseurs ?
• modéliser nom, adresse et n° de téléphone des fournisseurs dans une même table est une très mauvaise chose

[Senethril1]

EN fait j'avais commencé par faire le même schéma pour un site réalisé à l'aide du framework nommé laravel, cela me plaisait mais j'ai finis par reprendre l'idée de réaliser le site par moi même entièrement ou presque, seulement le schéma pour ce type de site s'affranchit de la plupart des concepts de logiques habituellement retrouvés, j'avais donc un peu trop hâte de fournir un exemple sur lequel je bloquais, Les types de données ne sont pas revus ainsi que les explications sur comment je considère réglementer l'utilisation.

JE conçois un objet comme sur un site de commerce, il a donc des propriétés parfois inutiles mais mal définies dans leur nature, je revois l'entièreté du plan pour vous apporter plus de précisions et par l'occasion toute son ampleur, il faut dire que passer par des règles du gestionnaire de laravel permettait nombre de choses complètement interdites en mysql classique tel que les opérations logiques OU ou ET entre un champ et plusieurs tables,je ne vous montre pas le schéma de base il ne décrit presque rien et n'est pas clair du tout.
(pas finis les types de données pour les tables à la droite de utilisateurs)


J'aimerais un avis critique et aussi des conseils pour la structure générale, ce qui revient que j'aurais râté, tout ce que vous pouvez me dire en sorte...

[escartefigue]

Bonjour,

Le modèle présente pas mal de tables, afin de faciliter la lecture et donc la critique, vous devriez scinder en sous-ensemble en commençant par le cœur de métier

C'est plus facile de s'atteler à plusieurs petites taches qu'à un énorme chantier

Et bien sur, ce premier sous-ensemble doit être livré avec ses règles de gestion, c'est le point de départ