Best practice to create large number of different type of products

Kentico always creates separate table in database for each page type and I'm not really sure how you could workaround it.

There is a way to reduce the amount of efforts for creation of those page types - create a BaseProduct page type and add all common fields there (hopefully most of fields are common) and inherit each new page type from BaseProduct, so you get all the fields from it automatically added.

Can you give an example of some of the different properties?

One thing to do is inherit page types. This means you have a base page type which all the other page types inherit properties from. Then even though you may have 300 different page types in the system, you could have a base one which stores all the base info.

Another option is to create a single page type, "Product", and have those custom properties be attributes of the page type. Meaning you'd have your single page type with a bunch of dropdown selectors going off to custom table data and storing the custom table's ID in the page type field. The downside of this is you need to lookup the data when you display the details page. So it could be quite a few queries when the page loads. Another downside is if you plan to use Kentico's Smart Search, you'd have to build a custom index to get those properties to properly index with the data you want.

Hi Iman,

I agree with Brenden's second approach. It's better to have a single page type for storing products. You can have 2 options of storing properties then:

1. Create all distinct properties in just one page type. It will be fine having up to 50-70 properties from my experience. In one of my projects I had 15.000 products with about 40 properties. If you implement caching accurately and will be using Smart Search index instead of searching in DB it should be fine. Or do you have much more?
2. Store properties in a dedicated properties table and reference products and properties in a many-to-many way.

Hi, thank you for your messages and solutions,

Some of the products are as follows:

• Electronics, Computers, Smart phones
• Foods, Grocery
• Toys, Kids and Baby
• Beauty and Health
• ... (and also their subcategories)

Each of them has its own custom properties, so we have to create a page type for each of them.

I think that it isn't suitable solution to create a base product page type and inherit other page types fields from parent page type. This solution only reduces the amount of our efforts to creating other page types but again, for each page type a new table is created with all the fields of the parent table (about 50-70 fields in each table an it's a terrible solution) and again we will have the problems.

Brenden, can you explain more about your solution? What is the use of this number of dropdown selectors?

Are you meaning that we store custom properties in custom tables and link that custom table to a field of page type?!

How can our editors fill the value of these custom properties in the Product application of Kentico admin panel?

Your custom tables define your custom properties. For instance, you have a custom table called product type. In there you have a few fields:

• ItemID
• ProductTypeName
• ProductTypeEnabled

It holds the following records:

• 1, Electronics, true
• 2, Groceries, true
• 3, Toys, true
• etc...

Then in your generic "product" page type you have a field called "ProductType". Set it as a integer field. Then set the control to be a dropdown list. In the dropdownlist field you can do a query like below to get all the product types from that custom table to dynamically populate:

SELECT '', '-- select one --'
UNION
SELECT ItemID, ProductTypeName
FROM CustomTable_ProductType
WHERE ProductTypeEnabled = 1
ORDER BY 2

This will then draw out the data and allow you to store a referenced ID from the custom table to the page type. The editors can then add or edit data in the custom table as well as in the page they are adding.

Hi Brenden,

I have to clarify, For example I want to create a product like motherboard with these bunch of custom properties:

[MotherboardID], [FormFactor], [Dimensions], [Brand], [Series], [Model], [CPUSocketType], [NumberOfCPUSockets], [CPUType], [NumberOfPowerPhases], [SupportedCPUTechnologies], [Chipset], [MemoryType], [NumberOfMemorySlots], [MemoryStandard], [MaximumMemorySupported], [ChannelSupported], [OnboardVideoChipset], [SLISupport], [CrossFireSupport], [PCIExpressx16], [PCIExpressx1], [SATA6Gb_s], [SATA3Gb_s], [SATAExpress], [M_2], [M_2Type], [SATARAID], [AudioChipset], [AudioChannels], [LANChipset], [MaxLANSpeed], [WLANChipset], [MaxWLANSpeed], [Bluetooth], [PS_2], [HDMI], [DisplayPort], [RJ45], [USB3_1], [USB3_0], [USB2_0], [S_PDIF_Out], [S_PDIF_In], [AudioPorts], [ComPort], [ParallelPort], [USB3_0Header], [USB2_0Header], [CPUFanConnector], [CPU_OPTFanConnector], [ChassisFanConnector], [WaterPumpConnector], [EXT_FanHeader], [ROGExtensionHeader], [ThermalSensorConnector], [MainPowerConnector], [Power12VConnector], [ThunderboltHeader], [FrontPanelAudioConnector], [TPMConnector], [SystemPanelConnector], [Jampers], [Buttons], [OSSupport], [Features], [PackageContents]

You can see that we have at least 66 custom properties for only one of our products. Saving only product type in a custom table isn't the solution.

Where can I save these properties and how can I fill the value of them in the Product application?

I think in you case Kentico CMS may not be the right option for the solution. What you are looking for is essentially a PIM system for managing the product info and use Kentico for the front end display.

All the product information would be housed in the PIM and Kentico will only house the reference or SKU. When product details are requested, you will pull the data from PIM using API.