Google-ing a bit you can find a lot of articles about best practices on relational database. If you think that they are exagerate in your case, you could take a look at "taxonomy" concept in wordpress, and implement something similar in laravel. On packagist you will find some package.

Usually, when i need to choose between 2 values in a table, i use boolean.

In your case, creating a separate table for only MEN/WOMEN is overkill. Use Boolean , where 0=Men, 1=Women . You just need to process the data a bit while reading saving it.

Don't, normalize better. Seehttp://laravel.io/forum/05-12-2015-has-many-through-relationship-depth?page=1#reply-24426

Personally I wouldn't recommend the "use boolean, where 0=Men, 1=Women" idea. Sure, you're saving few bytes, but you're sacrificing code clarity in a big way. If the data size really matters that much, use a database "enum" type field. But in most cases I'll just use a string because of the flexibility and clarity that it gives you. Many years ago I would have been concerned about the extra bytes, but as storage and computer speed has evolved, our priorities today should lean more towards clarity and simplicity.

About the original question, a products table that contains fields like model, season, and gender is absolutely fine. That's perfectly appropriate use of a normalized table. The only case when I would create a separate "product_attributes" table would be if new attributes are likely to be added/removed frequently, or if the attributes are not the same for all products (for example if only shirts have a "collar size" attributes, and only pants have a "inseam", etc. In that case I would add a "product_attributes" table describing each possible attribute, and a "product_attribute_values" table assigning values of attribute fields to products.