OOB Tables: When to Extend, When to Add Custom Fields

[Greg Guinn]

Hi,

I'm on loan to my company's ServiceNow development team, thus I'm not a ServiceNow developer. Please forgive my ignorance in advance. : ) Anyway...

My team is wanting to use the cmdb_ci_computer table to store computer/workstation/device data coming from an external source that has no awareness of the fields on cmdb_ci_computer; the external source's fields don't don't map logically/semantically with the fields on cmdb_ci_computer. They are pushing hard to add as many custom fields as necessary to cmdb_ci_computer. I'm pushing for extending the cmdb_ci_computer because, for one, I am uncomfortable modifying the schema of something I don't own. Secondly, my opinion is that once we add a custom field that is specific to the external data source, the cmdb_ci_computer table is no longer the cmdb_ci_compute table; it has effectively become the cmdb_ci_our_external_data_source table.

In addition, if we add custom fields to the cmdb_ci_computer, anyone wanting to extend that table in the future will have to handle (or at least consider) the custom fields we add because the extended table will necessarily inherit those custom fields, correct? What if the extender has a field that's the same name as one of our custom fields, but our custom field is, say, a different type? What then?

Thanks!

[Rogers Cadenhe1]

There are times when it makes sense to add fields to an out-of-the-box table. I've done work for clients who extended cmn_location to add four fields that were sys_user reference fields to hold employees who had responsibilities at that location. They only wanted to add a small number of fields and these fields were unlikely to clash with any future OOB additions.

But if I was asked to add a bunch of fields, I'd prefer extending the table. It's a better future-proof solution.

[User658787]

What information do they want to store about a computer that is not covered already in the table or in a table that is already related to cmdb_ci_computer? 

[Greg Guinn]

We don't fully know yet, honestly. We're going through the exercise of determining what fields from the external source we need to bring over. I can tell you this: Of the 47 external source fields to consider, only three map 1:1 "grammatically". For example, the external data source has Operating System, Domain, and Category, which the cmdb_ci_computer table has. Some of the remaining fields from the external source are semantically debatable at this point. For example, cmdb_ci_computer has "IP Address", whereas the external data source has "Ext IP Address", and "Int IP Address".

[User658787]

In the case of IP address you could create a network adapter record that is related to the computer CI, then assign as many IP addresses to that adapter as you needed to.  

But in general, I favor extending tables instead of editing tables provided by SN when possible to avoid the issues you already raised (everyone else who uses that table will be impacted for example).  If you will be running a lot of queries against the table you will want to think about what extension model you use.  https://docs.servicenow.com/bundle/london-platform-administration/page/administer/table-administrati...