Is this table structure good?

I'm going to create a table for holding set o开发者_运维知识库f options, right now its around 30 different options. But it will gradually increase month by month, if I set a table per field per option basis its going to have 30+ and the worst part I have to modify it whenever I add a new option, The options are are grouped. I was thinking something like this. A separate table to hold a group id of set of options, and for the option another table.

option_id | group_id | option_name | option_value

Thank You.

---

looks nice, but in my personal opinion, i would change option_id to ID, option_name to Name and option_value to Value.

group_id is good as it is, so you can know that it's linked to another table, as for the others, it's completely unnecessary. If the table name is Options, you normally assume that the field Value is the Option Value.

Hope that helped.

---

What happens if you would like to group already existing options that are in different groups? Is there such a requirement or is it even possible in the lifetime of your application that such need might arise? I'll suggest looking into the EAV data model, because you're scratching on the surface of something resembling it - since it's a broad and discussed subject, having read about what others have to say about it you might see whether you're missing something or not.