With the fantastic and flexible elastic data model that’s one of the main strengths of inriver, I thought that a thread where we can share our best data modelling tips & tricks would be helpful.
I’ll start with a few of the top of my head and in no specific order:
- Prepend the entity type id in front of the category id, for example “ProductMarketingText” and “ItemMarketingText” instead of just “MarketingText”. This allows for different sort orders, translations and alike, it’s a small thing that sometimes pays of well. My exception would be the ‘General’ that I usually re-use for all entity types at the very top of the sort order.
- Have an “Internal name” (String) for each entity type, that’s only used and shown inside inriver and is the display name. If you have a LocaleString as display name it will be empty if it’s not translated in all languages, which isn’t great. You can also write status and other information in the internal name field. For example “[Archived] Dishcloth 2000”, “Dishcloth 3000”, “[Q3] Dishcloth 4000”, which at a glance can provide valuable information on to the users in listings.
- Have multiple resource link types, at the very least we often have a “ResourceMedia” (images, videos, etc.) where sort order matters and a “ResourceDocument” where the sort order often isn’t relevant.
- Automatically set the fieldset based on existing CVL values, and if that’s not possible we often add a separate “Fieldset” CVL field as it can be useful and easier to set the fieldsets this way using mass update, Excel, etc. Instead of modifying it directly in the fieldset dropdown.
- Evaluate if it’s easier for users and channel consumptions to create a JSON/XML field on the entity and have an EditTemplate as the editor interface, or if an entity type and a link would be best, especially if you would have to use LinkEntities.
- Consider storing ‘bullet point’ content in separate fields instead of a single field, for example “USP 1”, “USP 2”, “USP 3”, etc. Having separate fields makes it easer with Excel exports, often in channel consumption and in translations as well.
- If you have the need for formatted text, consider using Markdown instead of an HTML WYSIWYG editor, being a bit ‘limited’ with how you can format can be a good thing if you have multiple channels consuming the information. Translations and doing formatting of the texts outside the PIM is also easier with Markdown since the formatting is maintained and don’t get ‘corrupted’ if you copy between multiple programs/formats and people.
- If you need a 3-level product hierarchy for example Series -> Product -> Item, consider inheriting down all the Series information to the Product entity automatically, as many channel systems might be limited to only the Product -> Item model.
Core concepts
I’ve not mentioned some core concepts and best-practices like soft-linking, etc. Make sure you read up on the elastic data model and don’t be ask questions if you have them, we’re all here to help.
Lastly
I’m really looking forward to your best data modelling tips & tricks, so please share!
3
-
Great share Roy Eriksson
I'll probably comment with more model tips in the future but to get started with one:
- Always leave a gap of 10 or 50 "numbers" in your index/sortorder for "Field Types, Specification Field Types, CVL values and Link Types etc..". It will save you a lot of time in the future when your model expands.
Also an idea Roy Eriksson is that you could update your original post with community users best tips.
2 -
Thanks Daniel Jansson, once we'll get some more great tips I can update the main post to keep them gathered in one place. So keep the tips comming! 👍
1 -
A couple of ideas from my end -
- Before deciding to store additional reference data for an attribute, it's important to determine whether this data should be treated as an entity rather than as an attribute. By identifying these entities, we can better organize and manage the data, which can improve the efficiency and effectiveness of the system.
- Consider implementing a logger entity to keep track of execution details specific to connectors and extensions. By doing so, users can easily access extension execution information without having to leave the enrichment portal, which can improve the overall user experience.
1 -
Great share Piyush chawhan!
-
Before deciding to store additional reference data for an attribute, it's important to determine whether this data should be treated as an entity rather than as an attribute. By identifying these entities, we can better organize and manage the data, which can improve the efficiency and effectiveness of the system.
Spot on, inriver is very strong with regards to both hard and soft linking and also inheritance of data being fully event-driven. You need to keep in mind and really consider how the channels will consume the data, the more entities they need to fetch data from to get the "complete picture" the more complex (=expensive) integrations tend to become, which is where inheritance of data can be really valuable.
-
Consider implementing a logger entity to keep track of execution details specific to connectors and extensions. By doing so, users can easily access extension execution information without having to leave the enrichment portal, which can improve the overall user experience.
We some times use connector states to store a log/status for connectors and integrations and build an application template as a viewer for the connector states. But the neat thing with having an entity that you use is that you can tie it to workareas and notifications and therefor perhaps act more quickly.
0 -
Before deciding to store additional reference data for an attribute, it's important to determine whether this data should be treated as an entity rather than as an attribute. By identifying these entities, we can better organize and manage the data, which can improve the efficiency and effectiveness of the system.
Please sign in to leave a comment.
Comments
4 comments