Bonjour à tous,
j'essaie d'optimiser mes bases données à l'aide l'outil Workbench et je me trouve confronté à une incompréhension.
Malgré mes recherches sur le web, je n'arrive pas à trouver un exemple percutant pour m'aider.
Quelles sont les différences entre une relation identifiée et non-identifiée ?
Dans mon esprit, lorsqu'une relation est non-identifiée, la modification ou suppression de la table fille n'aura aucune incidence sur le contenu de la table mère et vice-versa.
Est-ce que c'est bien l'idée ?

Voici une image de mon projet.


Si je suis ma logique, dans ma structure, la suppression d'un client n’entrainera pas la suppression de ses commandes (du coup est-ce que je vais tout de même avoir les données du client qui avait un compte ?)
De même, dans le contenu_commandes, si je modifie des infos dans les articles ou que j'en supprime, les infos de la table contenu_commandes ne seront pas affectées ?

Merci pour vos lumière !

Salut,
la logique que tu présentes n'est à mon sens absolument pas logique.

Si tu supprimes un client, comment pourras-tu faire pour identifier à quel client appartiennent ses commandes ? Tu te retrouveras avec des données orphelines avec des commandes sans client, ce qui m'apparait comme tout à fait incohérent.

Dans ton design, ta table commande_client est une table relationnelle et les deux colonnes devraient former une clé primaire composite, ce qui interdit la suppression d'un client qui a enregistré au moins une commande.

Ta table contenu commande est également une table relationnelle, donc les deux colonnes actuelles devraient former une clé primaire composite. Il faudrait en outre y rajouter une colonne « nombre_articles » ainsi qu'une colonne « date_commande ».

La gestion des catégories/sous-catégories est étrange : pour cette partie, ta table « sous_categorie » devrait en réalité s'appeler quelque chose comme « article_appartient_categorie » et ne comporter que deux colonnes, id_article et id_categorie en clé primaire composite. Mais tu devrais avoir une relation récursive dans ta table categories de telle sorte qu'une catégorie puisse comporter des sous-catégories, ce qui implique une colonne id_categorie_parent te permettant d'avoir des sous-catégories à niveaux multiples.

Enfin, pour la gestion des promotions, il faudrait virer les colonnes id_categorie et id_sous_categorie de ta table articles_en_promo, et ajouter les colonnes date_debut_promo et date_fin_promo. Puisqu'un article ne peut appartenir qu'à une et une seule catégorie, même si cette dernière est la sous-catégorie d'une autre catégorie (avec le système de récursion exposé plus haut), tu n'as plus besoin de ces colonnes.

Lis et relis tout ceci autant de fois que nécessaire, ça devrait s'éclaircir assez rapidement pour te sortir de l'impasse dans laquelle tu t'es engagé

Merci Cyrano d'avoir pris le temps de bien détailler.
En effet, j'avais repéré la bourde pour les clients à ne surtout pas supprimer (idem pour les articles)
Je vais bien m'imprimer et relire tes orientations !
Je débute en modélisation, habituellement je structurais à la main mais en générant des doublons ...
Je souhaite être "plus propre" et optimiser mes développement.

Encore merci.

Salut,
il est effectivement très important de ne jamais bâcler la modélisation d'une base de données.

Si ta base de données est bancale, même en admettant que tu sois un super-gourou du développement PHP, ton application finira tôt ou tard par être bancale. Donc il faut prendre le temps nécessaire et bien réfléchir.
Il faut comme tu semble l,avoir saisi éviter les doublons et les redondances, éviter autant que possible les colonnes avec des valeurs NULL, et ne jamais avoir de colonne avec des valeurs calculées. Ce sont des petits principes fondamentaux en matière de bases de données relationnelles.

Bon courage, et n'hésite pas à revenir demander des précisions si tu as un doute sur un point ou un autre en présentant ton idée et les motivations qui l'accompagne.