Вернуться   AXForum > Microsoft Dynamics CRM > Dynamics CRM: Blogs
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Опции темы Поиск в этой теме Опции просмотра
Старый 27.06.2019, 14:11   #1  
Blog bot is offline
Blog bot
22,737 / 777 (71) +++++++
Регистрация: 28.10.2006
crmtipoftheday: Tip #1280: To split, or not to split, that is the question!

The subject of today’s tip is highly debatable but Eric Regnier did do justice to it. (Want to start a discussion of your own? Email your tip to

In many implementations particularly complex ones, often comes a situation to determine if the same entity should be used for the different “types” (or categories). Say an insurance company implements claim management, there are multiple types of claims, each with their own set of fields and separate business logic/requirements. What do to? One claim entity for all or split into its own entity? Here are some quick pros/cons to provide some guidance.

Some assumptions to support the pros/cons

  • Entity in question is complex (>100 custom fields)
  • Entity has a high chance of evolving (especially in Agile methodologies)
  • Entity is a core/important entity of the system
Pros if split

  • Ability to segregate privileges per entity and therefore, have a simpler and more flexible security model. Although might be possible to satisfy requirements if it were one entity, security becomes more complex, e.g. using field level security (which has perf impact amongst other things.)
  • Ability to segregate customizations (plugins, workflows, etc) per entity aka separation of concerns. E.g. no extra lines of code to determine which logic to execute based on the type. Some performance gain; can scale and scope plugins/workflows/Flows/etc to execute on the exact type.
  • Less risk of regression. Changes occur only on the respective entity, and not touching the other types.
  • Leaner forms per entity. Don’t have to create separate forms or one form with JavaScript to auto-switch based on type.
  • Performance on searching. If one entity for all types and many fields require searching, might have performance impact. From my experience, I try to limit searchable fields (quick find) to no more than 10.
  • In database terms, entity model becomes more “normalized”.  Easier for developers and end-users (e.g. in Advanced Find) since only the corresponding fields are made available. Don’t have to think which fields are for which type.
  • If entity contains a lot of data (>1M), in split scenario, data is split and each entity can have its proper indexes.     
  • Might be cases where sub-types or even sub-sub-types are needed which make the entity model even more complex if it were one entity.

  • Reporting can become simpler or more complicated depending of the case. If split, can target specific type without additional filters on every report/view.
  • No impact on global/relevance/categorized search. All entities can be configured accordingly. Search at the entity level however will only get results from the entity selected.
Cons if split

  • On forms, dashboards and views/charts will have separate sub-grids per entity.  If required to see records in one sub-grid, then custom web resource or canvas app is required.
  • If same logic is required on each type, then will have to copy or rely on JavaScript/code not to duplicate the logic. For example, show/hide field on form with business rule. Will require the same business rule on every type unless a common JavaScript function is done (requires a developer).
  • There is no concept of inheritance in CRM/D365 CE, so if many fields are the same, will have to recreate the fields in every entity. Developer/customizer will need to be vigilant to ensure the datatype and names matches exactly.
Tîpp Jäår $0.02 + tax

Splitting entity is one of my favorite techniques, especially when it comes to security. But I knew I used it for something else in the past… Lo and behold, “how to update a record without modifying the modifiedon” or Keep your pants on and timestamps intact.

Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
crmtipoftheday: Tip #1222: View is not available error in App for Outlook Blog bot Dynamics CRM: Blogs 0 18.02.2019 15:11
dynamicsaxse: November 2018 Release – Dynamics AX2012 R3 update Blog bot DAX Blogs 0 15.11.2018 09:11
crmtipoftheday: Tip #1063: Do not touch currency system views Blog bot Dynamics CRM: Blogs 0 29.01.2018 04:21
Быстродействие метда TaxParameters::find Ace of Database DAX: Программирование 7 01.06.2017 11:46
wiki.dynamicsbook: Changes Made in Navision Attain 3.60 Blog bot Dynamics CRM: Blogs 0 02.09.2008 13:23
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Часовой пояс GMT +3, время: 23:16.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.