# Relational Data And KV Transformation

| Table No | No | ... | Name | birthday | cell phone | score |
| :-- | :-- | :-- | :-- | :-- | :-- | :-- |
| T24 | 1 | ... | Tom | 1982-09-28 | 1390811212 | 78 |
| T24 | 2 | ... | Jack | 1996-04-12 | 1801222187 | 91 |
| T24 | 3 | ... | Frank | 1982-09-28 | 1364571212 | 90 |
| T24 | 4 | ... | Tony | 1977-03-12 | 1391113134 | 65 |
| T24 | 5 | ... | jim | 1992-07-19 | 1579915611 | 51 |
| T24 | 6 | ... | Sam | 1978-09-12 | 1713665011 | 97 |
------------------------------------------------------------

3. Since every table in the entire database may have primary keys numbered 1, 2,..., n, in order to locate a row in the database, we need to add the Table ID to Key, which is the unique number of the table and the index's unique number Index ID. In this way, a row of data has a database-level global key. What about tables that don't have a primary key? TiDB will actually add a hidden column rowID to all relational tables. If the table has int Primary Key, then the value of the Primary Key will be used as the RowID, otherwise the Row ID will act as the Primary Key, where TableID is unique in the whole cluster, indexID/ RowID is unique in the table, and these IDs are of type int64.