Extended table now has two sys_ids, one referencing the table, and one referencing the parent (task)

[alexjyong]

In my dev instance, I modified the new_call table to extend task.  It now has two sys_ids columns, one for task, and one for its self. 

Right now, this doesn't seem like a problem; other tables that extend task also have this as well. Just curious as to why it is? 

In addition, to have new_call extend task, I edited the Table Field Validation business rule to not block on extending a table after its creation. Is this an issue? Or something that can be done, just need to be aware of XY and Z?

Edit: clarified that it has two columns, not necessarily two of the same values. 

[Harish Ragz]

Each record in the instance is identified by a unique 32-character GUID (Globally Unique ID) called a Sys ID (sys_id).

The same sys_id value will never be generated twice, ensuring every record created in every table in every instance in the world has a unique identifying value.

If two records have the same sys_id value, then one was copied to the other at the database level outside of the ServiceNow application. When created within the application, sys_id values are unique. The ServiceNow application and database should manage all operations on sys_id values. Typical end users do not see a record's sys_id and database administrators rarely use sys_id values.

[alexjyong]

I mispoke. What I meant to say was that it has two sys_id columns, not two records.

[Harish Ragz · Accepted solution]

Actually every table have it's own SYS_ID column. When we are extending the table (i.e parent table have also SYS_ID column ) with another table means we are extending their all columns (i.e including the SYS_ID column),so we will get two SYS_ID's (one is Parent sys_id and another is child sys_id).

But if you filter in the list(i.e child table's list) you will get only one sys_id.

[alexjyong]

Makes sense, wanted to make sure I understood it. Thank you!