Scalable Data Modeling for Spare Parts and Vehicle Compatibility in PIM

Hi Everyone,

I would like to get suggesstion about data storing on PIM and regarding with custom product attribute fields.

Our use case involves managing millions of spare parts and vehicle records, each with their own attributes.

Example:

spare parts : [Weight, Lenght, Height]

Vehicle:[ Make, Model, Year]

Our primary goal is to determine which spare parts are compatible with a list of vehicles. In some cases, a single spare part may be compatible with thousands of vehicles.

Currently, we store vehicles as separate products as we need to get make, model, and year for front-end purposes . For spare parts, we attach the corresponding vehicle IDs. At present, vehicle IDs are stored as comma-separated values in a free-text field. However, when customizing the front-end or using the API, free-text storage may encounter limitations. As an alternative approach, we are considering storing these vehicle IDs in a custom field and using a multi-select field to link each spare part to its compatible vehicle IDs. But this needs us to import millions of option values. We are considering this approach instead of relying on the related product functionality, given that both our spare parts and vehicle datasets are extremely large (in the millions).

Any suggestions or recommendations for handling this use case would be greatly appreciated.

Thanks for the detailed description of your use case — it’s a classic example of where scale and structure matter a lot in a PIM setup. Let’s walk through the options and how Dynamicweb 10 PIM is designed to handle this.

Products and attributes

Spare parts should be one type of product with attributes such as Weight, Length, Height, etc.
Vehicles can also be represented as products, but more commonly they are modeled through a data model with datasets like Make, Model, Year. This allows you to avoid duplication and makes importing/updating easier.

The compatibility challenge

You are correct that free-text fields (like comma-separated vehicle IDs) quickly become unmanageable and limit both API usability and performance. A multi-select field with millions of possible options would also be impractical, as you’ve already noted.

This is exactly the scenario where relations come into play:

Product relations in Dynamicweb PIM are designed to link one product (e.g. a spare part) to many other products (e.g. thousands of vehicles).
These relations are stored efficiently in a relational structure, not as free text, so they scale to millions of records.
You can filter, query, and expose these relations through the API in a way that’s much cleaner than parsing IDs from a string.

Recommended setup

Here’s how we’d suggest structuring your PIM in DW10:

Vehicle as product model
- Create a Vehicle data model with attributes Make, Model, Year.
- Each unique vehicle entry is a dataset (e.g. “Honda Civic 2020”).
- These become PIM products (vehicles) with well-defined attributes.
Spare parts as products
- Create a Spare part data model with attributes Weight, Length, Height, etc.
- Each spare part is a PIM product.
Linking spare parts to vehicles
- Use product relations (or the newer dynamic relations if you need more complex conditional linking) to connect a part to all compatible vehicles.
- A single spare part product can therefore relate to thousands of vehicle products.
- This avoids huge multi-select lists and keeps imports manageable (you import parts, import vehicles, and then import the relations separately).
Front-end/API benefits
- From the API, you can query a spare part and get its related vehicles directly, or query a vehicle and see all compatible spare parts.
- For the frontend, this is the most efficient way to filter/search (e.g. “show me all parts for a Toyota Corolla 2018”).

Why not multi-select fields?

Multi-select fields work well when the list of possible options is small and finite (tens, hundreds, maybe a few thousand).
With millions of vehicles, this approach becomes unscalable — you’d be importing millions of field values for every update.
Relations are the intended and optimized solution here.

Scaling tips

Import vehicles, parts, and relations as three separate data flows. This keeps your data cleaner and easier to maintain.
Consider whether you need every possible vehicle in PIM, or only those relevant to your parts catalog — this can cut down data volume significantly.
If you have compatibility rules (e.g. all Toyota Corollas 2015–2019 share the same part), you may want to use dynamic relations to reduce the number of explicit links.

As mentioned before - it might be a good idea to schedule a call with us to dig into the solution of this.

BR Nicolai

Developer forum