each item made out of 500 parts.
It takes 14 processes to manufacture an item.
each process involved 3 people
each of them need to keep track if there is a fault on the smaller parts and what is the reason of the fault.
each process has different fault reason.

Process 1 has 8 different fault reason
Process 2 has 6 different fault reason
Process 3 has 10 different fault reason
Process 4 has 5 different fault reason
Process 5 has 3 different fault reason
Process 6 has 4 different fault reason
Process 7 has 7 different fault reason
Process 8 has 6 different fault reason
Process 9 has 5 different fault reason
Process 10 has 8 different fault reason
Process 11 has 7 different fault reason
Process 12 has 6 different fault reason
Process 13 has 5 different fault reason
Process 14 has 3 different fault reason

Assume on average there is 7 different fault reason for one process.
This means that in total there will be 7 fault * 14 processes = 98 fault reasons and each process involved 3 people which means for each item, there will be 294 fault entries in the table ( 98 fault reasons x 3 user/process).
if the machine manufacture 40 items a day, i will have 11760 (294 x 40) entries in the table for each day. Within a year my table will have 4,292,400 rows!!
Do you think mysql is capable in handling so many records in a year ?

or instead of each reason one row, i shold just put one process fault reason in a row ?
for example i define the maximum column base on the highest reason for a process eg 10 (process 3). For processes that has only 3 different fault reason, i will only use the first 3 column to keep record of my data. The rest of the 7 column will be empty. Through this way i will only have 42 entries for one item (3 users/ process * 14). This means that in a year i will only have 613,200 rows of data.

Can someone advise which approach is better ?

4 million rows is easily within the capabilities of mysql

the normalized design (the first one mentioned) is better