How to proceed to create a Coursedatabase


I’m new to pimcore. Could someone with experience please guide me towards the proper direction?

I want to create a course database. To avoid facing big problems later on: Which of the options below should I choose? Which option shouldn´t I choose - and why? What did I miss?

My plan:
The uppermost layer contains fields which are the same for all courses.
The second layer: 3 types (video, web-based-training, face-to-face) with inherited fields - but also different fields.

In what way should I create a course:

  • a table? tried&tested - but it would be “rigid”
  • objectbricks? not rigid - but they would have to be added manually - or require a bunch of eventlisteners
  • tags? not rigid - but they would have to be added manually, and I´d have to check if they are already created

At the moment I´m for table and tags…
Which direction should I choose to be able to insert and report courses via API most easily?
Table would contain the fields which don´t change that often, while dates (for face-to-face courses) would be tags…

Should I create different versions of a course as variants?

Questions over questions…what´s the best practice?

Thanks & Bye


I have a question before I can reply with an answer.

What do you mean by “table”? I’m truly hoping here you’re not planning to have a course represent a new table in your MySQL database (apart from Pimcore’s object table). That would be a bad practice and completely unnecessary. Please alleviate my worries. :smiley:

Hi Tomislav,

I had in mind ONE table for all the courses - which would be filled with basic-info-columns, additional columns depending on the course type (yes, bloat/mostly empty columns - but easier to read) and a column for each new tag. If a tag already exists, no new column would be created. Each new course would only be a row.

So…I guess I must not create a “table” element below the parent-class (AllCourses), because otherwise for each new course a new table would be created? This would have been a terrible accident by me. The horror!

Thank you very much for making me notice what would have happened! I shudder…
Can you please tell me which elements to use - on which level?



hello Michael, as far as I understand it, one course is like one product for you. In the case of Pimcore this would mean that one course is one data object. Each course would then have different attributes, as defined in your data object class.

I think the main questions to ask are

  • how does your full data model look like
  • how will you import/export the data from/to the system (regular or irregular, CSV or API)
  • how much data are we talking about (hundreds or even millions of courses?)
  • how are the workflows when it comes to the data enrichment process (which users need which views and access roles)
  • which 3rd party systems will consume data and how?

… there are more but I think these are the most important ones to start with

I think you should follow @ckemptner’s advice. Your course should have a separate class, and attributes. You should think about where to place them (one central place for all courses or scattered around in separate categories), also, how does everything else link to those courses.

By no means should you go with multiple courses as a part of a single whole because you’ll certainly have some other stuff to worry about (like if you need a link to a course, or whatnot).

Anyway, the rule of thumb is: Chunk-ize your content as much as possible. For some general advice and practices, have a read here:

Thank you both very much! You´ve helped me very much to clarify for myself.

Regarding the questions:

  • Data Model: EER, a rigid Data Model is ok. It will be a transfer of an existing system - and its database. How many fields/ variables are needed is known by experience; it doesn´t change a lot
  • the data will be imported either by CSV, XML - or via API
  • around 300 unique courses. They occur in multiple flavours (version 1.1…1.3…1.8). I guess I can use the variants-system for this. But what´s best practice to map multiple occurences per course (on this date, at this place…)?
  • There will be some roles and custom layouts & views
  • No third-party-systems. Just the mySQL-database - and a server
  • other tables contribute info to the classes - e.g. the variants could be in another table in the database…

Can you elaborate on this sentence: “By no means should you go with multiple courses as a part of a single whole because you’ll certainly have some other stuff to worry about (like if you need a link to a course, or whatnot).”???

Current planning is: one table in the database for a course. Maybe another one for variants…a typical SQL-Database.
But how to design it in the backend via Pimcore?
My current planning is:

One class on the hightest level - for “AllCourses”: X input fields, and a selection for course types
one hierarchy-level down: the input fields are inherited, and depending on the selection additional input fields are shown
How do I provide the different input fields? Should they be grouped in ObjectBricks?

I want to list the courses in the frontend and the backend by category (…if they are of a certain type…if they have a certain attribute).



“By no means should you go with multiple courses as a part of a single whole because you’ll certainly have some other stuff to worry about (like if you need a link to a course, or whatnot).”

By this I mean just that you shouldn’t have a Courses object with, as you say, 300 boxes, each representing a single course.

Regarding the approach to a Course class, you have multiple choices.

First, inheritance: Be sure to tick Allow inheritance on this your Course class. Then, create a smaller Class which will envelop all the particular data on your Course, like topic, etc. This class would extend the Course class, and when you create an instance of it, it will have all the fields native to the Course class, and your “flavour” fields for this particular class. Read more about inheritance here:

Second, fieldcollections: you could go a different route if you need to create multiple “flavours” on a Course object: Fieldcollections. Read more about them here:

Basically, Fieldcollections work like this: Create a collection of Fields you’ll need for a certain instance of a Course. That’s your first “flavour”. Then create a second one, and go on until you reach all the “flavours”. Then, as you create a course, you’ll be able to add those Fieldcollections based on the “flavour”. The pros of this approach are that you can add multiple “flavours”, even some of the same type, to a single Course object. The cons are that it can get unnecessarily complex, fast.

Third, Object bricks: Now these are similar to Fieldcollections, but you can only add one Objectbrick instance at a time. This is a singleton approach. You’re effectively limiting yourself to a single instance of an Objectbrick, but allowing yourself to have a clear division of your “flavours”. Read more about Object bricks here:

You can also combine these different approaches into a single model which best fits your needs.

Regarding SQL, I wouldn’t worry too much about it. Pimcore has an extensive PHP API and it will do the heavy lifting for you in that department. You just need to create your Data Model properly.

Thank you very much! It helps a lot - and I just had a “paradigm-shift”!

“You shouldn´t have one course object representing a single course”: Ah, ok.
Up until now, that was my aim - as I could then list them “on the fly” in the frontend by querying for attributes and tags by creating CustomViews…and use GridView to show all the courses with all the attributes in the Backend…
Question: Why not? Performance?

Regarding Fieldcollections: I shied away from them as
A) they don´t support inheritance … can you recommend an article to make clear “this kind of inheritance” vs OOP-inheritance?
B) with Objectbricks I wouldn´t have to check if the fields already exists for that object/course (as with tags), as my - former - plan was: one object per course.

I´m still “rooted” in “SQL-table-think”… One the one hand, this makes for “highly structurized thinking”, but on the other, I have difficulties “switching concepts”. I´m more at home with PHPMyAdmin than Doctrine.

I´ve read most of the articles in the Documentation, watched most of the Youtube-Tutorials…Google a lot…but being a beginner I am struggling to digest/really comprehend it on a deeper level - rather than “read and understand it on the surface…”.

“It´s not the concepts/beliefs/facts you don´t know/understand that get you…it´s the ones you think you know/understand, but which are in fact different”. I think I just made this error.



Wait a sec… I think there’s been a miscommunication. I’ve been saying all along that you SHOULD have an object representing a single course. Just not an object which represents ALL courses. :smiley:

Ok…I´ve advanced a big step.

However, now I´ve encountered the next problems:
I´ve created a class - and a subclass, which should inherit from the class.

Alternatively, I´ve created a class and an ObjectBrick

…but in GridView, the inherited fields aren´t shown:

When trying to configure the GridView…

…I don´t succeed. Partially because I don´t know where to insert what. Be it for an ObjectBrickGetter or other Getters…

The documentation of GridViewConfig IMO is “suboptimal”, and lacks info the documentation normally provides…

Parameter: In which form? What can I insert here - and what would be the result?
ForwardAttribute: In which form? What can I insert here - and what would be the result?

I´ve Googled - but did not find examples how-to-do-it…

That would be the next step. The steps after that would be to figure out how to show GridFields based on SelectedValues, then to ex/import the data via API (, how to show different GridViews based on logged-in User ( and - finally - how to import it via csv or json…

I apologize if all this seems dumb. I´m a Newbie. We also could set up a call.
How much for about 1/2 hour of questions (but a warning: I´d prepare a lot of questions before hand and fire away…)?