mysql - How to reconcile ENUM / option values in relational SQL with accepted PHP values without having to maintain identical value lists in both places? -

i designing simple php form interface website , wish normalize dropdown fields. end, i've scrapped draft database schema had single table entire entry form (with enum values <option> input) , adopted normalized table schema.

i thought simple, it's not.

the server-side application uses resulting post values regenerate form on-submit because dropdown values not coincide database values, instead trigger actions or user errors. (these invalid entries prevented javascript still have validated.)

so php has know names , post values mean.

the javascript/html generated php has have same info same reason, should not use actual database index of each <option>, unless it's simple 1-5. (i assume) instead going give each option shorthand string value shared js & php, translated sql numeric value/index constant array.

this can supplied same php element controls acceptable values; "public" values have have common meaning in case either code edited, , private indices of each field name / value tuple meaningless without access meaningful static flag value.

i've been told not use "magic numbers" various articles i've read. can't use same flags values (boolean or bitwise) because assume they'd in 1 big table different dropdowns numeric/string value column , string name column.

a separate table each dropdown doesn't seem things any, unless specific dropdown has extensive logic attached it, 1 does. (i've separated out). if there 1 dropdown item, same problem exists: both db , app have list of each value set , mean.

if mysql controls order accepted values appear in, php still has know 1 which. if mysql stores values , generic names dropdown fields, still requires php know order go in (which subject change). , replace default (meaningful? canonical?) value option_id actual (descriptive) text description in dropdown (which subject change).

this requires php know in advance values mean, rendering relational table worthless except db-side validation (which steps on server validation , potentially destroys integrity of database if app logic changes) amounts fancier version of using enum.

what dry method doing (mysql / php)?

should use enum , let php keep track of each enum values mean?

should use int field instead of enum , let php determine numbers mean?