Database Table Design: normalization or not

Question

A Web Configurator (for customizable electronic articles) shall persist a user-generated configuration via a web user interface to a MySQL-database.

The available options are static, amount of 10 to 20 different options.

I cannot figure out which solution has more advantages. And I am asking for some advice, because this is a common question in database design.

Solution #1

1 table:

configurations:

• id
• option1
• option2
• option3
• etc.

Solution #2

2 tables and 1 relationTable (see below)

configurations:

• id

options:

• id
• name
• value

It does not matter to me whether it will be a unidirectinal OneToMany association with a join table or unidirectional ManyToOne association with a foreignKey on the option's side.

The question is, whether to have one table with about 10 to 20 columns , each for each option, eventually, the need to alter the database schema from time to time, if new options are required

OR

to have for every configuration entry about 10 to 20 associated option entries .

the configurations table could grow to about 2000 configurations per month => 20000 to 40000 option entries per month.

The query time to query a configuration and its associated options, if the options table has more than 1.000.000 entries could be high, right (Solution #1)? Is it a better option to query a row of a single table with about 20 columns (Solution #1)? Perhaps this is also a criterion. Are there drawbacks / pros / cons for any solution?

Answer 1

I would go with Solution #2. I would also add caching layer to the application for options table which will create for each configuration_id requested, a json object (array, list or whatever your language supports) with all options already queried, processed and ready to use.