locked
CRM 2011 Architecture - Can growing fields of Contact entity cause problems? RRS feed

  • Question

  • Hi

    We have 5-6 different type of Contacts in out CRM 2011 On-Premises. Each type of contact required its own custom fields. Due to that Contact Entity have so many fields. Possibly in future business will ask us to create another Contact type and we might have to add more fields to contact entity. I am concerned because of the growing number of fields on Contact Entity. Can anyone please answer the following questions.

    1. Is there any limit of Maximum fields per entity?

    2. Having a big Contact entity, Will it affect the performance of the system?

    3. If above can cause any issue what is the best approach to design?

    Thanks in advance.

    Wednesday, July 3, 2013 3:58 PM

Answers

  • Hi,

    This is a problem that often comes up with my Enterprise clients. The problem is one of user experience vs. performance. There is a theoretical limit of 1024 fields per entity (based on SQL Server 2008 R2s limit of non-wide table )  - but you also need to consider your data width so that the data doesn't exceed the maximum 8060 bytes per row. So if you've got lots of long text fields that are being filled in al the time, you'll quickly reach this limit. For this reason it's worth picking multi-line text fields instead of text fields.

    Users prefer having everything on one form, but as the number of fields goes up the time taken to render/load the form will go up in a non-linear fashion.

    If you have many contact types, it's important to set the fields/sections as hidden by default and show them dynamically as needed rather than the other way round - this can greatly reduce load times.

    As for a more scalable solution, you can take the decision to move as much information as possible into related entities associated via 1:N relationship. I tend to look at what is really needed by the user on the same form as the time the record is being created, and move the rest into related entities. It's important to use a 1:N so that you can use the cascade ownership on the relationship to ensure the user always gets access to the related records. Sometimes it's just not practical to have the user create these records manually, and you can use a plugin to create it and also associated it with a N:1 link so that the user simply has to click on the link on the form to open up the additional info rather than navigating to a subgrid.

    Of course it's a judgement call you'll need to make - and often if you carefully design your entity model you find that the fields naturally lend themselves to being on separate entities anyway rather than all on the contact. 

    hth


    Scott Durow
    Blog www.develop1.net    Follow Me
    Rockstar365
    If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"

    • Marked as answer by jattscorpion Friday, July 5, 2013 7:25 AM
    Wednesday, July 3, 2013 5:58 PM
    Answerer

All replies

  • Hi,

    This is a problem that often comes up with my Enterprise clients. The problem is one of user experience vs. performance. There is a theoretical limit of 1024 fields per entity (based on SQL Server 2008 R2s limit of non-wide table )  - but you also need to consider your data width so that the data doesn't exceed the maximum 8060 bytes per row. So if you've got lots of long text fields that are being filled in al the time, you'll quickly reach this limit. For this reason it's worth picking multi-line text fields instead of text fields.

    Users prefer having everything on one form, but as the number of fields goes up the time taken to render/load the form will go up in a non-linear fashion.

    If you have many contact types, it's important to set the fields/sections as hidden by default and show them dynamically as needed rather than the other way round - this can greatly reduce load times.

    As for a more scalable solution, you can take the decision to move as much information as possible into related entities associated via 1:N relationship. I tend to look at what is really needed by the user on the same form as the time the record is being created, and move the rest into related entities. It's important to use a 1:N so that you can use the cascade ownership on the relationship to ensure the user always gets access to the related records. Sometimes it's just not practical to have the user create these records manually, and you can use a plugin to create it and also associated it with a N:1 link so that the user simply has to click on the link on the form to open up the additional info rather than navigating to a subgrid.

    Of course it's a judgement call you'll need to make - and often if you carefully design your entity model you find that the fields naturally lend themselves to being on separate entities anyway rather than all on the contact. 

    hth


    Scott Durow
    Blog www.develop1.net    Follow Me
    Rockstar365
    If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"

    • Marked as answer by jattscorpion Friday, July 5, 2013 7:25 AM
    Wednesday, July 3, 2013 5:58 PM
    Answerer
  • Hi Scott,

    Thanks for your reply. I might consider creating related entities. Thinking of how I will display the fields from related entities on Contact form? Grid? 

    Thursday, July 4, 2013 2:03 PM
  • Hi,

    A Grid would show the data - but I'd ask if the users really need it on the form since sub-grids also reduces performance of the form load.

    hth


    Scott Durow
    Blog www.develop1.net    Follow Me
    Rockstar365
    If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"

    Thursday, July 4, 2013 2:09 PM
    Answerer
  • Yes, user want to see the information on form. We have a plan to create separate form for each type of contact.
    Thursday, July 4, 2013 3:17 PM