>>If you're 100% sure that your design regarding these fields would not change, then you can put the fields into Member table and it will improve the performance. I'm not sure you will get a significant improvement, though.
>
>Well, if I want to locate members having one to x choices selected, where the members table would have two millions records, assuming that each member has at least two choices, it would make the one to many table with about 4 millions records. I would assume it would be much faster to simply SQL into the member table by searching on its field.

Some important information is missing:
Do all members have one or more choices?
What's the average number of choices per member?
If you want to find which choices are selected for a particular member then the single table might be faster. But if you need to determine which members have a specific selection of choices then the current setup might be quicker since you're presumably selecting from a much smaller table.
My 10c,
Viv