Design DOUBT: Separate Tables vs. Single Table for Email-Based CIs

[Daniel_san]

Hello,

I want to track both Functional Mailboxes and Distribution Lists in the CMDB — both are email-related CIs and would share most of the same fields. What would you recommend?

• Option 1: Create two separate tables extended from cmdb_ci (one for each type).
  • In this case, I would define the necessary fields for each CI type in its corresponding table.
  • However, when creating a list for SOW in sys_ux_list, I can only point to one table and its columns at a time, which makes this setup less flexible for a combined list.
• Option 2: Create a single extended table, e.g., u_cmdb_ci_email, and distinguish the two CI types using a field on the table (for example, a custom field like u_type or u_email_type).
  • In this case, I would include all fields needed for both CI types in the same table, even if some fields are only relevant to one of the two types.

[Hanna_G · Accepted solution]

Hi @Daniel_san 

There are a few important considerations when deciding whether to create custom tables; including licensing impacts, ongoing maintenance, scalability, and how the data will be used and maintained over time.

Option 2 (a single extended table with a type field to distinguish between Functional Mailboxes and Distribution Lists) is generally more efficient in terms of future maintenance and licensing. You can handle differences in data requirements through form design, UI policies, and conditional logic.

This approach also simplifies things like sys_ux_list configuration, reporting, and data management — all while minimising licensing complexity and overhead.