Best practice to create large number of different type of products

Iman Emran asked on May 16, 2019 16:01


We plan to create an e-commerce site and the number of our products and their types is very high. There are about 300 different product types, each with separate technical specifications.

So one method is to create a new page type for each product type and set custom properties on the field section of that page type, but there are two issues with this method:

1- Kentico for storing custom properties creates separate tables for each page types and this is a very large number of tables.

2- The main problem is when you want to export site with this number of product types, Kentico creates a very big SQL SELECT query so the MS SQL Server can not execute it even if you increase the time outs of the query execution and always makes an error on exporting site.

Is there a better way to create this number of different product types with different custom properties?

Recent Answers

Roman Hutnyk answered on May 16, 2019 16:51

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.

0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on May 16, 2019 16:53

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.

1 votesVote for this answer Mark as a Correct answer

Dmitry Bastron answered on May 16, 2019 19:00

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.
0 votesVote for this answer Mark as a Correct answer

Iman Emran answered on May 16, 2019 20:28

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?

0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on May 16, 2019 20:37

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 --'
SELECT ItemID, ProductTypeName
FROM CustomTable_ProductType
WHERE ProductTypeEnabled = 1

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.

0 votesVote for this answer Mark as a Correct answer

Iman Emran answered on May 16, 2019 20:58

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?

0 votesVote for this answer Mark as a Correct answer

Rui Wang answered on May 17, 2019 19:51

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.

1 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.