Inheritance and relationships between base and child classes in terms of field values

[SB87]

I think I already know the answer, but want to be certain. If we take the [task] and [incident] tables for example, I am aware the [incident] table extends the [task] table. When looking at API Explorer, I can see the [incident] inherits the fields from [task] + has its own unique fields. I can also trace the sys_id of the incident and locate it in the [task] table. 

My questions:

1. If a task and incident have a field in common, for example opened_at, then does this field actually exist in the incident table at all, or is it just observing the field stored in the [task] table?
2. Will the value of the opened_at field always match between the [incident] and [task] table for the same sys_id, or can it ever be different?

I get why inheritance is used, it avoids field duplication and a base class like [task] serves many different ticket types, but what I am unfamiliar with is the instances of the fields. For example, if I look at the [incident] table using API Explorer I can see that all the fields from [task] + [incident] are listed, but do the [task] fields actually exist in the [incident] table or is this just the illusion given to the end-user where the fields shown are just reflecting what is actually found in the [task] table?

Thanks in advance.

[HIROSHI SATOH · Accepted solution]

Your understanding is correct. In ServiceNow, the [incident] table extends the [task] table, similar to the concept of inheritance in object-oriented programming. Here are the detailed answers to your questions:

1. Does the opened_at field actually exist in the [incident] table, or is it just observing the field stored in the [task] table?

   • The opened_at field does not actually exist in the [incident] table. It is stored in the [task] table, and what you see in the [incident] table is just a reference to this field. The [incident] table inherits fields like opened_at from the [task] table, but does not contain them directly.

2. Will the value of the opened_at field always match between the [incident] and [task] tables for the same sys_id, or can it ever be different?

   • Yes, the value of the opened_at field will always match between the [incident] and [task] tables for the same sys_id. Since the [incident] record is an extension of the [task] record, the fields like opened_at are shared, meaning they will have the same value.

3. In API Explorer, when looking at the [incident] table, I can see all the fields from [task] + [incident]. Do the [task] fields actually exist in the [incident] table, or is this just an illusion for the end-user where the fields shown are just reflecting what is actually found in the [task] table?

   • The fields from [task] do not actually exist in the [incident] table. They are stored in the [task] table and simply reflected in the [incident] table due to inheritance. What you see in the API Explorer as [task] fields in the [incident] table are just references to the fields in the [task] table.
     
     

ServiceNow table structure (see documentation for details)

Table Structure	Description	Characteristics	Applicable Scope
TPC (Table per Class)	Class Table Inheritance	Each class has its own table, making the data structure clear and easy to manage. Flexible customization is possible.	Used in most standard tables.
TPH (Table per Hierarchy)	Table per Hierarchy	All classes in a specific hierarchy are stored in a single physical table. Introduced to efficiently manage the hierarchical structure of task tables.	Specialized for task tables.
TPP (Table per Partition)	Table per Partition	Extends TPH and allows for the creation of multiple partition tables. Used in CMDB hierarchy tables to support large-scale data models.	Specialized for CMDB hierarchies.