Database Management
Table hierarchy
Tables can extend one another. The base table holds the shared fields; the child inherits them and adds its own. ServiceNow stores an extended hierarchy in a single physical table with a sys_class_name discriminator, which is why a query on the parent returns child records. The classic example is task, extended by incident, problem, and change_request.
Custom tables created in the global scope use a u_ prefix; tables inside a scoped app use the app's x_ namespace prefix. Every record is identified by a 32-character sys_id, a globally unique identifier that never changes and is what reference fields store.
Dictionary and performance
Column definitions live in sys_dictionary - type, max length, default, mandatory, and whether the column is indexed. Indexes speed up queries on frequently filtered or joined columns. Audit records field-level history when enabled. sys_db_object holds the table metadata itself.
Good design habits
- Extend
taskwhen a custom table needs assignments, approvals, SLAs, or work notes. - Prefer reference fields over free text for relationships.
- Use dot-walking for reporting rather than duplicating data.
- Respect table naming conventions; renaming a table after data exists is costly.
Traps
Extending a table inherits all parent fields and any later additions. Deleting a table deletes its data. A sys_id is unique per record but is not a friendly number - that is what the auto-numbered number field is for.
Rule of thumb
If the new table needs to behave like work - approval, assignment, SLA, activity - extend task. Otherwise extend nothing.