Newbie/Basic question about PIMCore data structure

Hi @ all,

I’m more or less a newbie when it comes to PIMCore. Nevertheless we plan/think about to build a new PIM-System based on PIMCore. Therefore we are currently playing around with the solution. Now I have a basic question about data modelling in PIMCore. Based on my current knowledge there are 4 possibilities to structure data within PIMCore. You can build/define:

  • classes
  • object bricks
  • Field collections
  • Classification stores

Now honestly speaking I’m not sure about the pros/cons of the individual methods and what are their intended use cases.
The issue is that in our use-case we have to handle thousands of different product categories with different parameters and parameter-sets. We work in the tool and machine industry and have to handle therewith highly technical product data with tons of relationships and dependencies. Now the question we are currently struggling with is: What is the best method to structure the technical parameters of our products? Our current point of view is to use either the classification store or field collections as it makes no sense to create thousands of object-bricks and different classes.

Does somebody have an advice or an idea what would be a good approach?

Thank you in advance

Best regards

I am pretty sure that there are a lot of different solutions for your problem. For the technical data, I would use classifications IF you don’t have relations in them like: a relation to another object or to assets. If you have relations, you have to use object-bricks and create a lot of different object-bricks. Nothing wrong with that. Object Bricks are also localisable and inheritable, so thats fine. I wouldn’t use Fieldcollections though, cause they are not inheritable.

Hello dpfaffenbauer,

thank’s for your fast reply. Well, now I have a couple more questions :slight_smile:

The issue is that we are fighting more with “dependencies” rather than with “relations” between objects. Example: Lets assume you try to define the data model for the product category “spanner” (Schraubenschlüssel). In the data model you have to respect that the spanner, or better to say the opening width of the spanner can be either metric or in inch. So the “dependency” from our point of view would be, that when somebody is adding a new “spanner” to the system (so really a new physical item) he first has to enter of course all the basic data like art. no. etc. and then he has to select if it is a metric or inch type spanner. Depending on this selection he has to enter the opening width in mm or inch.
Now the question is if there is a possibility to create such “dependencies”?

My second question is, if there is the possibility to create dependencies/relationships between classes (not objects)? The idea is that when i create an object in class “a” I also have to enter the information’s for the automatic creation of a new object in class “b”.

The third question is if it is possible to group classes/class definitions “deeper” than just one level? Means something like:
|_________Class definition

Thank you very much for your support

Best regards


  1. I believe I kind of understand what you mean here. With this one way to go is just to have a width field with no unit. When using that in the code you can check the spanner type and based on that know the unit. With editing UI it is more tricky if you need to update it “live” somehow based on some information filled. This would need custom components or some extjs code. Components like calculated value, dynamic text field or iframe might be useful here.

  2. I am not sure what exactly you would need here. For some specific not out of the box automation you can use event listeners or defining parent class with custom code.

  3. No, this is not possible now. I looked into the code and it is grouping classes in class definitions only to one level (either based on Group parameter or automatically from class name). It seems grouping is used only in the class definitions admin panel for presentation (to show it in a grouped tree) and it has no other functional purpose. Might be a case for a PR to change it to allow subgroups.