Dynamics Community Forum Thread Details

Best Practices for When to Create a New Table for Lookup VS Adding Fields to a Table?

The amount of columns in our contact table is quickly growing very large. We have several departments using our CRM and there are dozens of columns (and more on the way) that are only used by one department. Putting all these columns into the contact table and forms is taking up a ton of space.

For example, there's one department that pretty exclusively uses a "College" column. It was suggested that we consider creating a "College" table in which we add new colleges as needed and then make a lookup column in the contact form for this table. This would help with our reporting but I don't see how doing this with this column or others would help with having too many columns in the contact table.

Does anyone have a good process or rule of thumb for determining when to make new entities and dealing with large amounts of columns in one table?

From a performance perspective you would want to reduce the number of joins that would occur. Therefore I think the primary point to consider is whether a new table/entity would be used on its own or would it usually be used in context of the contact table. If the department that uses the college table would not typically query for related information in the contact table then it might make sense to separate the tables. However, if this department typically needs to query for data in both the college and contact tables then it might make more sense to not split the tables and keep "college" as a type value within contact.

From a storage perspective the total amount of space used will not differ greatly in either case unless you have duplicate fields.

As for cluttered forms and views you can define separate forms/views to match the needs of the various departments.

Quick Links

Leaderboard