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.
Sign in to participate in this thread!
We'd like to thank these amazing companies for supporting us
The Laravel portal for problem solving, knowledge sharing and community building.