I would just… use the hex as the value (because you want to use it immediately), and when it comes time to store it in the database, translate the hex for storage. (or for that matter… just store the value. an INT field holding 1 2 3 4 or 5 is the same as an INT field holding 16777215 (FFFFFF).
Hi @Jack_Tauson_Sr, if the hex value is being used in the frontend only, you might store it on a data-* attribute (say data-color) instead. This way it won’t get submitted with the form (or included in form data to be sent with AJAX) and you don’t need to preprocess the actual value to only submit the numerical part.
But as @m_hutley noted, why store it in the database with an entirely different value in the first place… just convert hex to int and vice versa.
As already set. Remove the id column in your database and make the color code column the primary key. It makes no sense to have the same color two times in the db, so it’s a perfect primary index to use the color code.
The backswing of this of course is that you will need to validate the data received from the form, regardless of the method used.
You’re giving a defined set of options (Blue, Red, etc) to the user; the color space contains 16 million values, so you’d need to validate that the form input is one of the colors you accept. (You would have to do this even if using 1,2,3…, because a user could send 0, or 100).
If these include the exact colours you want e.g. blue, which is #0000FF, then I would have thought just a data-colour=‘blue’ or data-colour=‘magenta’ should suffice.
If they don’t match what you are after, then couldn’t you pass in the colour names and use a lookup table of your own?