Bonjour à tous

Pour mon projet, j'ai besoin de stocker dans MYSQL, une couleur fournie par un utilisateur que je récupère avec un formulaire method="post"

La valeur récupéré par le post est étrange. par exemple, pour le rouge, je vais récupérer %23FF0000. Donc je fais un petit traitement php pour ne garder que FF0000. Est-je besoin de faire ce traitement avant stockage?

Ensuite, vient le stockage . J'arrive à stocker cette valeur uniquement en faisant un champ en CHAR(6) Ce qui me parait abérant puisqu'il s'agit d'une valeur numérique hexadécimale.....

Ma question est donc:

Quelle est la meilleur des bonnes pratiques pour stocker dans Mysql une valeur Hexa sur 3 octects?

Edit:

Je viens de voir que je peux stocker une valeur numérique de 3 octects (MediumINT) dans my SQL
L'idée est alors de transformer directement en PHP la valeur hexa en décimale puis de la stocker dans la BDD.
Ca fonctionne, mais il y a peut-être mieux?

-
Edité par Nui Prabpai 3 septembre 2020 à 5:22:47

Bonjour,

Le %23 est le code pour le dièse en hexa ... il y a peut-être un problème d'encodage soit de ta page, soit du composant ColorPicker, soit de l'échange entre PHP et la BDD. Cela pourra être embêtant par la suite. Donc soit tu corriges ce problème d'encodage (si il existe), soit tu maintiens le traitement pour remplacer le %23 par un # ...

Perso, j'utilise un ColorPicker pour Boostrap, et je récupère bien un # en sortie de formulaire ...

Côté BDD, si tu n'as pas besoin de traiter la valeur pour éclater les 3 segments du code couleur (R, V et B), alors un VARCHAR(7) est pertinent. Tu stockes le # et les 6 caractères derrières (de 0 à F).

Si tu as besoin de traiter indépendamment chaque segment couleur, alors le plus pertinent c'est de les stocker dans trois colonnes distinctes (R, V et B) TINYINT UNSIGNED (de 0 à 255).

Hello et merci

Tu m'as mis sur la voie et j'ai donc résolu le problème du # (j'ai passé un moment à me demander ce que pouvait être le %23! et c'était tout con)

Je reste quand même dubitatif sur l'utilisation d'un VARCHAR(7) qui consomme 7+2 octets soit 3 fois plus qu'une valeur RVB qui peut tenir sur 3 Octets (On va me traiter de radin lol)

-
Edité par Nui Prabpai 3 septembre 2020 à 11:49:06

Nui Prabpai a écrit:

une valeur RVB qui peut tenir sur 3 Octets (On va me traiter de radin lol)

Oui mais sur trois colonnes ... et cela t'oblige à éclater ta chaîne héxadécimale et à la convertir en 3 entiers ...

Nui Prabpai a écrit:

Je reste quand même dubitatif sur l'utilisation d'un VARCHAR(7) qui consomme 7+2 octets 

En fait ce serait 7+1 octets, et tu pourrais t'affranchir du dièse et utiliser un CHAR(6) ... donc 6 octets ... ça reste deux fois plus on est d'accord mais sans tout le tralala de conversion ...

Nui Prabpai a écrit:

On va me traiter de radin

Grave !

-
Edité par Benzouye 3 septembre 2020 à 14:47:14

Merci en tout cas.

Mon coté radin vient de l'époque où j'avais 15 ans (j'en ai 50 maintenant) à cette époque, je passais des nuit en programmation.(puis passé 30 ans sans toucher à la moindre ligne de code, d'où mes questions d'un autre âge sur ce site) Je participais souvent à un concours dans un magazine dont le titre était "1 kilo pas plus" le but étant, pour être gagnant, de concevoir le meilleur jeux sans dépasser la ligne rouge d'1 kilo Octets! La programmation en assembleur s'imposait donc et il fallait user d'imagination pour économiser le moindre octet.