---
sourceDocument: Brazil ServiceNow AI Platform Administration
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-administration

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil ServiceNow AI Platform Administration

ft:clusterId :

    - platadm

bundleId :

    - platadm

workflow :

    - Platform


---

# Table flattening

# Table flattening {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Table Flattening

Table flattening in ServiceNow refers to storing a hierarchy of related tables as one consolidated table in a relational database.
This approach affects how data is stored and queried, impacting system performance.
ServiceNow offers three extension models for handling table hierarchies: Table per class, Table per hierarchy, and Table per partition.
Show full answer Show less  

## Extension Models and Their Implications

* **Table per class:** Each table in the hierarchy is stored in its own physical table. The parent table stores copies of all descendant records. Queries require joining multiple tables, which can cause performance bottlenecks, especially when querying from the top of the hierarchy. This model is the default for most system tables and does not benefit from flattening.
* **Table per hierarchy:** The entire hierarchy is stored in a single flat physical table named after the parent table. A class name column identifies the descendant table of each record. Queries are faster as they avoid joins by filtering on the class name. This model is used for the Task table hierarchy on MySQL databases. To enable this model on Oracle databases, customers must contact Technical Support.
* **Table per partition:** Similar to Table per hierarchy, but the logical table is split into multiple physical partitions to optimize database resources like column count and row size. Each partition stores different subsets of records. Class name and class path columns help constrain queries, improving search performance further. This model is used for the Base Configuration Item (cmdb) table hierarchy on MySQL databases. Oracle customers must contact Technical Support to enable it.

## Practical Considerations for ServiceNow Customers

* Understanding which extension model your tables use is crucial for diagnosing performance and optimizing queries.
* Most system tables use the Table per class model by default, which might present performance challenges with complex queries involving multiple classes.
* Table per hierarchy and Table per partition models offer better query performance by avoiding multiple table joins, but their use is currently limited to specific hierarchies and database platforms.
* For Oracle database users interested in Table per hierarchy or Table per partition models, contacting ServiceNow Technical Support is required to enable these features.
* Knowing the extension model helps customers plan data management strategies and troubleshoot performance issues related to table hierarchy queries.  
Table flattening stores a hierarchy of related tables as one table in a relational
database.

## Extension models {#c_TaskTableFlattening__section_lsz_nvx_cbb}

The system offers these extension models to store a table hierarchy on a relational database.  
{#c_TaskTableFlattening__table_chh_wbf_dbb__entry__2}

| Extension model | Flattens tables? |
|-|-|
| Table per class | No |
| Table per hierarchy | Yes |
| Table per partition | Yes |
[Table 1. Available extension models]

{#c_TaskTableFlattening__table_chh_wbf_dbb}

## Table per class {#c_TaskTableFlattening__section_gcd_t2y_cbb}

The Table per class extension model stores each table of the hierarchy in its own
physical table on the relational database. Each physical table uses the table prefix of the
source table each stores a different class of records. An example of the Table per class
extension model is the Asset \[alm_asset\] table, and its child tables: Hardware \[alm_hardware\],
Consumable \[alm_consumable\], Facility \[alm_facility\], and Software License \[alm_license\]. The
parent table of the hierarchy, Asset, stores a copy of every record in its descendant
tables.

To find records in the Table per class extension model, the system queries records from
multiple tables and joins the results. For example, when searching for hardware in a related
facility, the system must join results from the Hardware, Facility, and Asset tables.

Table joins cause a performance bottleneck on relational databases. The more classes a query
includes, the worse the query performance. Therefore any query for records from the top of the
table hierarchy has the worst performance because it requires joining all descendant tables.

The system uses the Table per class extension model by default when creating tables. Most
system tables also use the Table per class extension model as there is no performance benefit
from flattening them.

## Table per hierarchy {#c_TaskTableFlattening__section_qqk_52y_cbb}

The Table per hierarchy extension model stores an entire table hierarchy in a
single flat physical table on the relational database. The physical table is named after the
parent table of the hierarchy, such as Task. The physical table contains all records of the
table hierarchy and assigns a class name column value to each descendant table of the hierarchy.
The system uses the name of the source table as the class name value. For example, Task records
can have class names such as Change, Incident, or Problem.

To find records in a table hierarchy, the system queries the physical table and uses the class
name column to constrain the results. Since such queries do not require joining results from
multiple tables, the system provides better search performance.

The system uses the Table per hierarchy extension model for the Task table hierarchy on MySQL
databases. Other tables use the Table per class extension model because there is no performance
benefit to flattening them. To use Table per hierarchy on an Oracle database, contact Technical
Support.

## Table per partition {#c_TaskTableFlattening__section_d5h_v2y_cbb}

The Table per partition extension model stores an entire table hierarchy in a
single flat logical table on the relational database. Each logical table can have multiple
physical storage tables called partitions supporting it. Each partition optimizes
the database resources available to a physical table such as the column count, index count, and
row size. The system adds a partition whenever the logical table needs additional relational
database resources.

Each logical table is named after the parent table of the hierarchy, and each supporting
physical partition consists of the logical name plus a partition name. For example, the Base
Configuration Item \[cmdb\] table starts as a logical table with no partitions. Suppose your
hardware configuration items consume enough database resources that the system creates a
partition called cmdb$par1 to store them. Later, computer configuration
items could consume enough database resources to warrant the system creating a second partition
called cmdb$par2 to store these records.

Within each logical table, the system assigns a class name column value to each descendant
table of the hierarchy. For example, within the Base Configuration Item logical table there are
records with class names for Application, Computer, and IP Router. The system also assigns a
two-digit class path value to each descendant table of the hierarchy. The class path is based on
the table location in the hierarchy. For example, the parent class Hardware might have a class
path such as /!!/!D and the child class Computer might have a class path
such as /!!/!D/!!.

To find records in the Table per partition extension model, the system queries the logical
table and its partitions and uses the class path column to constrain the results. Since these
queries do not require joining results from multiple tables, the system provides better search
performance. In addition, the class path reduces the total number of records to search, which
further improves search performance.

The system uses the Table per partition extension model for the Base Configuration Item \[cmdb\]
table hierarchy on MySQL databases. To use Table per partition on an Oracle database, contact
Technical Support.
* **[View a table hierarchy and the extension model](https://www.servicenow.com/docs/IVxM5b3pBuCBagUQP1jfGw)**   
  Determine the extension model used by a table.