cooper collier 12/4/2017 1:37:39 PM
This is what we do also.. It is a great way to do it.
But it does have shortcomings. Nothing is perfect. You end up making what I call LIST tables, that clutter up the dev environment. You also need to specially train users to not change or delete existing LIST entries. If a choice is changed, all previous records using that choice change.. (sometimes that's a good thing... ). If they delete a choice, all previous usages will default to the ID number of the deleted choice.
Plus consider when your choices are small and limited. Maybe for family relation. (Parent, Grandparent, Sister, niece)... You really don't need or want a separate table... but you only want maybe the owner to add the new relation type. If you let his kids do it, you would end up with, (Pinky buddy, BFF, etc)
So while the suggested solutions are excellent.
I think the functionality would still be very useful to have.