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.
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.
I’m really looking forward to your best data modelling tips & tricks, so please share!
Please sign in to leave a comment.