Table Structures — frequently asked questions - Support and Troubleshooting

Table Structures — frequently asked questions Issue .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Find answers to frequently asked questions about table structures in ServiceNow, including the three extension models (TPC, TPH, and TPP), task flattening, hybridization, storage aliases, glomming, and how these structures affect performance and schema changes.

Frequently asked questions What table structures are used on the ServiceNow platform? ServiceNow uses three table extension models: Table Per Class (TPC), Table Per Hierarchy (TPH), and Table Per Partition (TPP).

Table Per Class (TPC) TPC is the standard table structure used for general database tables. In a parent-child table structure, all direct descendants inherit fields and columns from their parent table. A record for a child class has a corresponding record in the child table and in each of its parent tables. Each record contains the fields specific to its class, plus the sys_id field that is common to all tables in the hierarchy.

Table Per Hierarchy (TPH) TPH was introduced in the Dublin release and applies only to the task table hierarchy. All classes in the hierarchy are stored in a single physical database table named "task." This eliminates the need for inner joins when querying descendant tables of task, which improves performance for users.

Table Per Partition (TPP) TPP was introduced in the Jakarta release and applies only to tables within the CMDB hierarchy. Like TPH, the CMDB table is a single flattened table. The difference is that TPP allows multiple partition tables to be created. Partitioning enables more columns to be added without reaching database limitations — specifically the 64 KB static row size limit and the 64-index limit. Note that TPP table queries look different from task table queries.

Can I choose the extension model for a table? No. The platform sets the extension model when a table is created:

Standalone table or extension of a standalone table — uses TPC. Extension of a table in the task hierarchy — typically uses TPH. In some circumstances it can be created as a TPC table, creating a hybrid TPH/TPC hierarchy. The most common circumstance is when the overall size of the task table exceeds a threshold at the time the new table is added. Extension of a table in the CMDB hierarchy — uses the extension model specified for the base table in that hierarchy. This is typically TPP, unless the hierarchy was not converted to TPP when upgraded to Jakarta, in which case it uses TPC. The extension model is set only on the hierarchy's base table. If empty, TPC is the default.

Why was TPH introduced? TPH was introduced in the Dublin release to improve query performance on the task table by eliminating the inner joins required when querying descendant tables in a TPC hierarchy.

What are the benefits of TPH? With a single physical task table, the inner joins required when querying descendant tables are eliminated, which improves query performance.

What are the drawbacks of TPH? TPH creates a single super table made up of many tables, which increases the risk of reaching database limitations:

64 KB static row size limit 1,000 column hard limit 64-index limit (up to 128 indexes depending on the underlying database version) When a physical storage column must be created on the task table, an ALTER operation is initiated. Because the task table is a large super table, schema-level changes — such as adding columns, adding indexes, or changing field lengths — can take a long time. The ALTER process copies all data from the live physical table to a temporary table, and the time required depends on the size of the task table.

What is task flattening? Task flattening is the process of converting the task table hierarchy from table-per-class (TPC) to table-per-hierarchy (TPH) — combining multiple physical tables into a single large super table.

What is hybridization? Hybridization reverses task flattening for a direct child hierarchy of the task table — such as Incident or Problem — by creating and populating TPC tables for each table in that hierarchy. Only hierarchies that are still TPH can be hybridized. Once hybridized, the process cannot be reversed.

When is hybridization considered? Hybridization is considered when the task table approaches the database limits of 64 KB static row size or the 1,000-column limit, and it is not possible to either drop obsolete columns or redesign the data model to avoid adding excessive columns — for example, by introducing standalone related tables.

How hybridization works Analysis is required to identify the best candidate hierarchy. The chosen hierarchy must contain fields used only within that hierarchy, so those fields can be dropped from the task table after hybridization, reducing the static row size and total column count. All tables in the chosen hierarchy are converted to TPC tables.

After hybridization, joins are needed between the hybridized table and the task table when retrieving data. Any insert, update, or delete operation generally runs against multiple tables.

Important: Hybridization is irreversible and can affect performance. Only consider this option after all other alternatives have been exhausted, and thoroughly test the impact on a non-production instance before applying it to production.

What is a storage alias? A storage alias record holds information for TPC and TPH tables that identifies how logical and physical elements are mapped in the backend database.

TPC tables — the application element name matches the physical column name. For example, a field named u_outage on a custom table u_test appears in the database as u_outage. TPH tables — elements exist as logical elements and map to a physical column on the task table with a generated name. For example, a field named u_test that is flattened from the UI logically shows as u_test but maps physically to a field on task named a_str_1. With TPH or TPP, the physical field can be longer than the logical field's max_length.

Storage aliases are also used when table or element names exceed the character limits of the underlying database. If a table or element name is longer than 30 characters, the name is shortened and the alias is used in the underlying physical table. The platform maps between the long names and their aliases when running SQL against the database.

What is glomming? Glomming applies to TPH tables and allows multiple logical elements that have no direct relationship — such as sibling and cousin elements — to be mapped to a single physical storage column in the task table. This helps reduce the risk of reaching database limitations such as the 64 KB static row size limit, the 1,000-column hard limit, and the 64-index limit.

Glomming also applies to TPP tables for the CMDB hierarchy, with a difference: TPP requires storage aliases for every table that inherits a field from the base table where the field was added. With TPC, the storage alias is specified only for the table where the field is added.

Why does the time to create a column on a table vary? When a new dictionary entry is created, one of two things occurs:

The system attempts to glom the new element to an existing physical column. This applies only to TPH and TPP extension models. If no physical column is available to glom to, the system runs an ALTER on the task table to create a new physical column. When an ALTER is required, the time to create the column depends on the size of the task table. The ALTER creates a temporary table and copies all data from the live physical task table to it. This process runs in the backend database and is not visible in the UI. Because the task table is a super table that can contain millions of records, this operation can take a significant amount of time.

Release .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } All supported releases

Resolution .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Not applicable

Related Links .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Table Flattening

Table Extensions and Flattening