I'm no expert however I'd be interested to see what others would see wrong with this way of handling the issue.
You have products, now suppose the attributes to these changes. Maybe some you want to know it's colour, others you might not. How do you handle all these different attributes without creating a column from here to the planet Pluto or tables also for that matter.
So this would be my way of attacking the situation.
Have a Product Table with the following columns:
Now lets say you have a "black" "jacket" that is "large" in size, for "winter".
Then the table would look like so:
ID - Attribute - Content - Product_Id
1 - colour - black - 12345678 2 - type - jacket - 12345678 3 - size - black - 12345678 4 - season - winter - 12345678
So when it comes time to processing the logic you are merely select via product_Id where attributes match a particular attribute. Now with a huge range of items this would make one heck of a table. Thus very hard to index and search, well very resourceful intensive in the least part.
This is where you could then create a "Tag" Table that belongsToMany products aka "Product Table".
Taking it a step further you could then have a Category table that a "Product" BelongsTo.
Taking it a step further you could then segregate upon the first chracter of the attribute thus creating a mass of tables that would then provide a systematic procedure for storing all the products. It then depends what you know now at design stage and how many products you wish to store.
Does this make sense?
What are other peoples way of attacking this?
If you don't need the variants to be indexable/searchable then (ie only display on product pages), then I would probably stuff them in a text column (json encoded)
If you do need them to be indexable/searchable - you could look at:
Sign in to participate in this thread!
The Laravel portal for problem solving, knowledge sharing and community building.
The community