I am upgrading a website to enable product variants - currently the website only provides standalone products but there is now a requirement to provide variants of a particular product, e.g. size or colour. The aim is to enable the site admin to easily insert/edit product variants.
The current structure is as follows:
table product
=============
id
name
description
category_id
price
stock_level
The fields 'price' and 'stock_level' will now need to be relevant to each product variant.
A product can have multiple combinations of variants, e.g:
Product ID 5 - Size: Small, Colour: Black
Product ID 5 - Size: Small, Colour: Brown
On the front end there are two dropdowns to select the variants (Size and Colour). Upon selecting the required variants, the values are posted to a PHP script which runs an SQL query to check if that particular variant combination is available.
I am struggling to come up with a solution for this. I have currently created the following functionality, which I think is the starting point:
Ability to create/edit variant TYPES e.g. Size or Colour:
table variant_type
==================
id
name
Ability to assign values to variant types, e.g. Small, Large, Black, Brown:
table variant_type_value
========================
id
name
variant_type_id
I am struggling to come up with the design for the table(s) that will store the product variant combinations (including their price and stock level).
Bear in mind, on the backend, there will be a form to "Add a new Variant" - on this form the admin will need to select 'Size', 'Colour', 'Price' and 'Stock Level' when adding/editing a variant.
I think the easiest way would be to have a Product table; that would have all the details of the variants in it, by including the foreign keys for the Product table, as well as the Size and Colour tables:
table variant
=============
variantID
productID
sizeID
colourID
stock
price
table product
=============
id
name
description
category_id
table size
==========
sizeID
sizeName
table colour
============
colourID
colourName
So you can get the details for the variants by joining all four tables together. Information that relates to the product in general goes in the product table, and you can add extra types of variant by creating new tables and linking them in the variant table.
Editted to add:
This way, you'll need to add extra tables if you want to add a new type of variant. You could also get around it by merging all the variant possibilities into one variant table:
+--+------+------+
|ID|Type |Option|
+--+------+------+
|1 |Colour|Brown |
|2 |Size |Small |
+--+------+------+
You'd then have multiple foreign keys from variantInfo in the main product table.
I don't tend to like that - I don't like have multiple types of information stored in the same table. I just think it's confusing, and you need to make the programming logic more complicated. If you want to have extra variant types, I'd recommend just setting them all up now - it's a little extra work, and some of them won't be used, but I think it's a lot easier to maintain.
Related
Does anyone have any previous experience or ideas on how to proceed in the product filtering section by category on the e-commerce site?
Because the filter field in the left menu will vary according to the product category. The memory filter should appear in the phone category, but the body (S,M,L) filter should appear in the t-shirt category. The project was built in Laravel. Options and option values models are available. Should the option_id be added to the category table and set accordingly or manually?
Thanks in advance.
You can use pivot table for this purpose. If each category has its own filters and you have a filter table (you name it option here), you must create a pivot table like category_option to store categoty_id and option_id. This will help you when building filter menu in category page. Next use another table to store product_id, option_id and value for that option to store values for each individual product.
There are many different answers to satisfy different online store needs.
A lot of the example I see don’t take into consideration **inventory and images ** and treat styles and sizes as attribute like tags and try to be flexible. This seems wrong to me. My Product that hasMany styles/color that hasMany Sizes.
Here is how i want to layout it out
Product
id | name | price
1 | shirt | 10.00
^ Styles < Images
id product_id name id styles_id filename
1 1 red 1 1 image.jpg
2 1 blue
^ Size
id sku styles_id name inventory
1 n1 1 m 50
2 n2 1 l 50
I don’t see many examples of this but this is what makes sense most to me. Am i totally wrong and bad to do it this way? With styles having its own table I can use a FK with images to load different looks of each style
I know one flaw is that what if I have a product that has only one style and one size. Like a winter coat. Then I to use extra tables. Visually with PHP I will just make it all one form. Will I run into an issue when i start working on cart and orders?
Note: I am using CakePHP
Response to the parent child method
Yes I have seen that before, Wouldn't you have repeated fields or empty fields, for example your table would look like this
id role color size inventory price name
1 parent - - - - artShirt
2 child red m 20 50.00 -
3 child red l 20 50.00 -
4 child blue s 20 50.00 -
5 child blue m 20 50.00 -
how would you link img to products that are red?
id product_id image
1 2 redImg.jpg
1 3 redImg.jpg
the concept i really like is called Parent Product - Child Products.
The Parent Product is given a sku for reference, but its not a buyable product. It represents the product, like the ArtSir Shirt. It contains a product description for ArtSir Shirt, qualities, keywords, etc.
the Child Products are the actual buyable products. the shirts. there is one record per child product with the sku, color, size, price, weight, inventory, etc. they are related to the Parent product by the parent product sku. for most merchants inventory is critical so having a db record per sku is really the only practical way to do this. (not to mention if you need distinct UPC or EAN codes)
the parent products and the child products can all be in - one simple happy db table. like a family :-) You call the parent product with its sku, then get the child products with the parent product sku.
and then when you get the child products, you have the option to filter out the ones with no inventory and not show them.
Showing product pictures on a product page for specific colors -- so this has nothing to do with the products being buyable or not. this is the presentation. the simplest (hack) is to put that information in the Parent product record. fields for Color 1, photo link, Color 2, photo link, etc
Otherwise you could have a separate db table to do this. Just try and confine its tasks to the presentation.
Always pass a product id to the cart - then the cart looks up the product price in the product table. If you pass the product price openly, then it can be easily hacked. When you look up the price you can also confirm inventory.
Suggest that there be one step before billing - where you check price and inventory again to confirm everything is correct before charging the customer.
==============
edit in response to question. you asked:
"Wouldn't you have repeated fields or empty fields, for example your table would look like this"
yes you will have empty fields. in 1985 or 1995 that was important. its not important any longer unless you are running your web site on a machine from that era.
bottom line you have to be able look up a sku and get the price and inventory. you could put arrays or data structures into a field.
but then you are having to pack and unpack them every single time you make a db call.
how would you link img to products that are red?
you can hack it by creating fields for the parent product to hold the image links, a color reference, a name, etc. color01, photolink01,color02, photolink02, etc. its a hack but it will work.
remember you are pulling all the page display information from the parent product. so this is just more display data.
you also have the option of having a photo field in the child product record. which you might need for product feeds. so then you could take the color - photo results from the child products, and use that to create the display.
otherwise make a db table for the display. and that table could also help with uploading the product photos and assigning them to the correct product.
I'm developing a Magento store for a vehicle accessory company. There are a number of vehicle specific items that need Make/Model/Year attributes, however I can't find an extension that allows creation of relational attribute dropdowns - I need three dropdowns, whose options change dynamically depending on the previous dropdown selection, for example:
Dropdown A has four Vehicle Makes. Choosing a Make then populates the Model dropdown with a specific set of options and so on for the Year dropdown.
Is this possible in Magento? I've looked at some of the Make/Model/Year extensions, but they're all text inputs - too much room for input error by staff members. I've also tried VehicleFits but it isn't working/throws a lot of errors and it appears development has ceased.
I've searched high and low, any help would be greatly appreciated.
It's not possible to create dependent product attributes directly or straight forwardly under Manage Attributes. But you can make your attributes depend on each other by creating Configurable products.
Lets say you have 2 colors (black and blue) and 2 sizes (L,XL) and you want to make your colors depend on sizes.
At first create 2 attributes size and color of type dropdown under Manage attributes and create the attribute options and values. and Assign it to the right attribute set.
Now create the simple products , lets say product A with size L and color Black and product B with color Blue and size XL.
Now create a configurable product lets say AB and associate these two simple products A and B. Save the product.
If the customer opens the product AB and if they choose size L they can find only color Black. This is how you can make your product attributes dependent on each other.
Source: here
Or may be this is what you are looking for:
http://www.magentocommerce.com/magento-connect/dependent-custom-options-configurable.html
Hope it helps.
I was wondering if anybody has ever tried to mass import custom attributes into a Magento Database before? My client has a Magento store that specialises in selling musical instruments, and wishes to add a Google Shopping Feed (using the extension of that name by Rocket Web) to sell the products on Google Shopping. The problem is that i need both an MPN (Manufacturer Product Number) and a Brand (so for instance Gibson) for the shopping feed to work, both of which are not automatically uploaded by the stores POS system.
The way that the POS system currently works is when a product is added, the title / SKU number / description / price etc are all uploaded to the Magento store, which means the client does not need to add the product twice. The problem is that as MPN and Brand aren't necessarily out of the box attributes, the POS system does not upload either of these to Magento, and therefore I now have 1,000 products without them and they are apparently crucial to the Google Shopping Feed extension.
I'm currently working on getting a table of each of the products SKU, MPN and Brands from the local database of the POS system (of which each of the products has all 3), but once i have it my question is this: is there a simple way for me to reference the products currently in the Magento database (most likely by SKU, as both databases contain the same SKU for each of the items) and apply two custom fields to each of the products: MPN and Brand? I've created custom 'MPN' and 'cat-brand' attributes (which i can use the Google Shopping Feed to map to the custom attributes) and looked inside the Magento database but i cant find them anywhere, but i found a table called 'catalog_product_flat_1', which i imagine is a flat DB used for indexing or something, but it looks perfect for achieving what i want, in that i could easily search for SKU and apply two custom attributes as columns for each product. Something tells me it isn't going to be that easy though.
Any thoughts would be a great help, thanks for your time.
Magento uses an EAV data model, which means your attributes are broken up into multiple tables. Take a look at any tables with 'entity', 'eav', 'attribute', or 'value' in their name if you want an idea of how it all works.
What you're probably looking for is catalog_product_entity_varchar or catalog_product_entity_text. In those tables, entity_id is your product ID number (different from SKU, but you can link a product_id to a SKU) and attribute_id corresponds to the eav_attribute table.
In short, what you want to do is look at your eav_attribute table, pull the entity_type_id, attribute_id fields for your MPN and cat-brand attributes you made, and then you can insert your data into catalog_product_entity_varchar. (or _text if your attributes use that instead)
I'm trying to get my head around eBay like structural database.
Given that each type of products has different columns I had to get products table then products descriptions table which is a meta table with key and value columns with product_id as foreign key for Products table
I've also got Specifications table which is hasAndBelongsToMany relationship with Subsubcategory table (which has belongsTo with Subcategory and then belongsTo Category relations)
So I've got joining table for Specifications Subsubcategory then also got Specification_Category which Specifications table belongsTo.
Now. I want my users to select a product with all those specifications of the product when they want to create a product selling page or have an option to create their custom product then enter those specific details into the Product Detail Meta Table based on pre-defined columns that are read from Specifications of that Subsubcategory.
To give you an example:
I'm now adding Specification using Scaffolding feature of Cakephp and I have a form with Name ie - 1TB, Specification Category - Hard Drive Capacity (belongsTo) and Subsubcategory - ie. Laptops, Desktops (hasAndBelongsTo)
Is this the correct way to structure something like this?