Excel et base de données mysql

Bon ben çà y est, j'ai ouvert un ticket sur nuxit... Et je vais peut-être aussi , quand même, demander de l'aide sur le forum Wamp, en parallèle. En fait j'aimerais vraiment bien avoir plusieurs solutions qui fonctionnent vraiment bien, histoire d'avoir plusieurs cordes à mon arc, surtout au niveau de cette base de données qui est quand même le nerf de la guerre...

Description pour la table commande des champs identifiants pour l'exemple:
On peut utiliser un numéro de commande unique(c'est ça qui détermine qu'un champ est identifiant, que le système puisse le retrouver à partir de sa seule valeur ou plusieurs comme c'était le cas de notre Pierre Dupont auquel on dit rajouter sa date de naissance pour pas confondre 2 Pierre Dupont). Numéro de commande permet de retrouver n'importe quelle commande, par recoupement l'utilisateur qi a passé la commande.
D'autres champs de données de la table "commande" sont date de commande, articles commandés, montant de la commande.
Par contre cette table contiendra comme valeur identifiants le nom et prénom + date de naissance reporté de la table utilisateur. A partir de là on peut retrouver et trier ce que l'on veut.

C'est à dire : pour un utilisateur quelles sont ses commandes. Pour une commande quelle est l'utilisateur qui a passé commande, etc...tout les tris et regroupements sont possibles.

Je n'ai pas regardé votre fichier Excel et je me doute qu'en parlant de botanique cela n'a rien à voir, sauf pour le principe.

Le but de l'analyse est de regrouper en entités thématiques qui permettent un traitement informatique parfois loin de la logique humaine. Où la logique humaine guidée par la méthode intervient c'est pour faire ces regroupements qui permettent de faciliter le développement de la partie purement technique(SQL) et déterminer la logique du regroupement que cela implique. n ordinateur n'ayant aucune logique c'est une bête machine à calculer, ou plutôt ici à faire des recoupements et tris. D'où l'importance d'avoir des entités qui permettent de lui faciliter la tâche ce que ne peut faire une seule table et implique des redondances.

Plus concret un exemple d'un modèle logique de données pour une commande:

https://particular-course.blogspot.com/2014/05/exercice-corrige-mcd-gestion-de-commandes.html

Comme vous pouvez voir dans ce cas d'école il faut ajouter à l'existence des tables 'utilisateur' et 'commande' une table 'article'. Cela évite de multiplier des données inutiles car redondantes et de pouvoir gérer chaque item représenté par une entité(une personne, une commande, un produit). Cela permet une plus grande souplesse et l’optimisation des traitements par la facilité à retrouver et utiliser chaque table de façon croisée. Donc moins de données à traiter quand on en cherches une.

Voilà en espérant avoir été un minimum clair(mais sommaire) et fait comprendre que le rôle de l'analyse et de la conception est primordial car tout le reste en découle:
_la facilité(ou pas) de faire le programme avec les outils SQL, PHP, HTML.
_de la maintenir et de permettre des ajouts
_du temps de traitement et l'intégrité des données soit l'assurance que le programme fonctionne et fonctionnera

Un programme aura d'autant plus de facilités que les entité logiques(les tables) sont bien organisées et reliées par rapport à un but. Il sera fonctionnellement plus efficace (en plus des autres problèmes que ne pas le faire peut impliquer) que le programme(SQL) ait à trier plusieurs tables avec une donnée à recoupée qu'une table unique avec multiplication et redondances à lire pour trouver la ligne dont il a besoin.
Multiplier la même donnée su une seule ligne est une erreur qui rendra le traitement plus lourd, le poids de stockage nécessaire et au fil du temps amène au problème auquel vous êtes confronté: le temps de traitement par rapport au nombres de données ne permet pas une gestion efficace des données, de leurs tris et modification puisque le programme n'a pas de repère fiable :
les identifiants et recoupement entre les tables qui allège la charge de travail/donnée à parcourir en n'utilisant que les identifiants et les rapports entre les tables plutôt que des lignes à la suite qu'il doit parcourir au petit bonheur avant d'arriver à celle qui est nécessaire. Bon c'est pas vraiment ça mais je vous laisse vous pencher sur la méthode qui est mieux expliquée et dont je résume maladroitement une dizaine d'étapes.

La première :
Faites une liste de toutes vos données existantes.
Ensuite:
Les regrouper
Puis:
éliminer les doublons et ajouter celles éventuellement nécessaire.
etc... jusqu'au modèle de tableS que l'ordinateur cette bête sans discernement peut utiliser et qui correspond aux liaisons nécessaires de vos informations.