How many fields is 'too many' in a table?

The most obvious sign a table requires normalization that I've seen is fields ending with integers: CouponCode1, CouponCode2, CouponCode3.. you get the point. There will be exceptions to the rule as always though.

Database tables can legitimately have 30 or more fields in them. What you need to look at is the normalization of the data and whether that normalization makes any sense. It will normally change in the future, as well. But, you want to try to minimize that.

For instance, if you have a table that has addresses in it, do you include the city, state, and zip code fields in that table? Or, do you only include one field that "points" to a record in a separate table for those values? The separate table would contain unique city, state, zip code combinations. The effect of splitting the data into two tables is a reduction in the amount of data stored (most likely but not absolute) but a bit of added complexity when you go to run queries against the database. Now, you have to deal with 2 tables instead of just one. But, on the bright side, it's much cleaner, and much smaller (likely).

The real answer is it's okay to leave the city-state-zip data in the address table in the right circumstances. Or, you might want to "normalize" it out. Both are okay.

Find a good database administrator and hire them short term to review the plan, if it's in the budget. It will pay off in the long run.

Thirty fields is not too many - you just have to make sure your data is properly normalized (for which there are plenty of guides on the web).

Based on your edit where you specify that many columns will be option-type fields which may be added or deleted over time, I would suggest the following is a better idea.

BaseTable:    Id    NonOptionFieldsOptionTable:    Id    OptionName    OptionValue

Then you can tie all your options to the base record. This will mean you won't have to be adding and deleting columns to tables all the time ly normalized way to achieve what you want.