Probable conflit html/PHP

Bonjour,
Comme je te l'ai indiqué dans ma première réponse :
NB: Pour poster ton code, tu devras utilises les balises de code.
Explications disponibles ici : https://codes-sources.commentcamarche.net/faq/11288-les-balises-de-code

Merci de nous reposter ton code correctement pour qu'on puisse le copier/coller si besoin

Penses aussi à ajouter quelques htmlspecialchars() autour de tes variables PHP contenant du texte ..

Ok je ne savait pas ce que vous vouliez dire par conditionnelles.

"Ça revient à meubler le NULL d'une BDD par un mot doux ou bien expliciter un caractère donné à une variable pour traiter une fonction. ex: 'A' dans la BDD deviendrait 'Activé" pour l'usager. "

Donc dans ce cas il faut que le programme pour chaque contenu (une lettre) sache à quoi corresponde "A" pour pouvoir l'utiliser. Ce qui revient à avoir une table d'équivalence A veut dire activé, etc... donc on se rajoute du travail en plus et rends la base de données inexploitable sans le programme qui doit transformer la valeur raccourcie en sa valeur réelle.
Imaginons que nous voulons rajouter une valeur possible dans la table, il faudra modifier le programme pour cela aussi pour que par exemple la valeur B qui ne veut rien dire en elle même corresponde à ce qu'elle veut dire.
Imaginons que nous voulons utiliser la base de données dans un autre contexte. Il faudra refaire le programme qui contient la table d'équivalence.
Même chose si nous devons faire une nouvelle fonction sur le même site qui doit afficher activé il faut rajouter une couche dans le programme qui lit la valeur du champ("A" par exemple)

Tout cela c'est des complications et du temps de travail plus risque d'erreur qui sont évitable en gardant une donnée comme elle doit être: avec un sens et représente quelque chose. La plus petite entité de sens, c'est l'exemple du nom + prénom:
ce sont deux entités différentes et pour savoir qui est une personne les 2 vont ensemble, il existe plusieurs Mr Dupont, peut-être même plusieurs Dupont qui ont le même prénom, pour les différencier il faut rajouter la date de naissance mais retenir "D" pour Dupont ne permet pas de savoir dans la base que le nom est Dupont) par elle même(la valeur "activé". Donc il faut que dans le programme on stocke D = Dupont et M = Machin etc...pour pouvoir convertir une valeur qui sinon ne veut strictement rien dire et est inutilisable.

C'est pour cela que je parle de doublon, 2 occurrences de la même chose nécessaire donc le double de travail et de risques d'erreurs toujours nécessaire(+ le double de temps de réponse et de processeurs qui doivent travailler, de pollution des serveurs informatique, de consommation électrique...bon je schématise mais c'est l'idée cela ne correspond pas toujours au double mais ce sera toujours plus cher, long etc...). Et à l'intérieur d'une même base quand il y a 2 valeurs différentes ce sont 2 champs de données différentes. Cela pourrait être dans une même table le champ "donnée réelle": valeur "activé", "abréviation": valeur "A".
Dans ce cas le programme permet de changer dans le modèle de nos données(les tables) la valeur abrégée à utiliser. Sans cela il faut changer le programme et la base de données si on veut changer l'un ou l'autre.
Avec une valeur représentée au lieu de 2 à traiter quand nous avons besoin de l’abréviation uniquement nous demandons l’abréviation à la base et l'obtenons et inversement.
Sans nous avons toujours à utiliser les 2 quand nous n'avons besoin que d'une et somme obligé de convertir l'une en l'autre à chaque fois.

Dans un cas nous conservons la cohérence du système d'informations(et l'intégrité/sécurité des données) en ayant chaque donnée qui représente quelque chose dans la base de données dont c'est le rôle et qui permet d'utiliser les fonctionnalités de la base de données(le langage SQL, les tris, ajout, modification, regroupements des données...).
Dans l'autre cas c'est beaucoup plus complexe, compliqué et nécessite de devoir aussi modifier le programme quand nous voulons intervenir sur les données. Ils deviennent dépendants l'un de l'autre et croyez moi sur parole (ou pas mais c'est un autre sujet libre à vous de vérifier) c'est une mauvaise chose quand 2 éléments séparés d'un même ensemble sont dépendants l'un de l'autre. Cette séparation est même essentielle sur le web.
Le langage HTML décrit les contenus d'une page tandis que CSS permet leur mise en page.
Séparer les 2 permet de présenter différemment le même contenu aussi bien que d'utiliser la même présentation pour d'autres contenus.


NULL signifie qu'un champ n'a pas de valeur, s'il en a une alors il n'est pas nul et cela peut servir.
Je vais encore prendre une exemple pour essayer d'expliquer ce que je veut dire.
Dans l'écriture des tables d'un vendeur qui présente son catalogue d'article nous avons le champ couleur pour les objets qui existent en différentes choix de couleurs et pouvons différencier dans les stocks qu'il nous reste tel n,ombre d'objets d'une couleur et tel nombre d'une autre couleur.
Le champ NULL correspond à un objet qui n'a pas besoin de valeurs donc bien à une valeur nulle.

Table articles du vendeur:
Nom de l'article: texte obligatoire
Description de l'objet:texte obligatoire
quantités en stock: nombre obligatoire(0 n'étant pas une valeur nulle mais indique qu'il n'y a plus d'article et que si le vendeur veut en vendre il faut qu'il se fournisse à nouveau)
Couleur: un texte le nom de la couleur ou NULL


Si le champ Couleur est obligatoire un objet qui n' a pas de couleur(sous-entendu choix de couleur possible sur le catalogue) comme information à présenter ne peut être enregistré puisqu'il n' a pas de valeurs, à moins que l'on mette une information inutile (dans cet exemple de système et le rôle qu'il a à jouer) parce que un article qui n' a pas de couleur n'a pas à présenter le bouton sélectionner la couleur pour l'acheteur. Et cela est fait simplement par le programme en testant si le champ couleur vaut "null" qui est bien une indication aussi.

Une base de données sert à stocker des données mais n'est exploitable et cohérente que si elle reprends la logique interne de la réalité qui doit être représentée:
les couleurs différentes d'un article(qui permet de proposer des articles en différents coloris ou la possibilité de ne pas avoir de couleur indiqué, une valeur indicative et sa notation abrégée avec les correspondances pour savoir l'un à partir de l'autre; dans mon exemple 2 valeurs distinctes stockées dans la même table une par le champ "donnée réelle", une par le champ "abréviation".
En laissant le champ abréviation qui peut prendre la valeur nulle on peut enregistrer une valeur sans son abréviation(ce qui n'empêche d'ailleurs pas de pouvoir la rajouter plus tard en changeant NULL par l'abréviation voulue).

Voilà vous évitez beaucoup de contorsions, de devoir faire l'équivalence dans le programme pour chaque élément alors qu'elle peut exister directement dans la base pour l'ensemble de votre système d'informations, contorsions qui en plus de compliquer la vie ne correspond pas à la réalité des données à traiter et apporte le risque de stocker quelque chose d'illogique(un choix de couleur pour un article qui n'en a pas) et donc inexploitable et qui risque de flinguer toutes les autres données/rendent le programme inutilisable = tout à jeter pour refaire correctement et imaginez au fil du temps et de l'accumulation des données la perte que cela peut représenter.

Ah oui aussi cela rends les choses plus simples si quelqu'un d'externe à la logique du réel des informations se pointe et doit intervenir sur votre site(un informaticien professionnel par exemple). Il peut comprendre une partie de vos besoins et contraintes directement en regardant la base de données et intervenir plus rapidement sur votre programme car il saura où trouver les données(dans la base) et leur traitement(dans le programme) sans devoir s'arracher les cheveux.