My initial thought was that it referenced another taxonomy (i.e. an FK from wp_term_taxonomy.parent to wp_term_taxonomy.term_taxonomy_id). ORMs like Corcel are built under this assumption. However, I've done some digging and most information seems to indicate that it actually references wp_terms.term_id.
In the case of Corcel, I think that this coincidentally works - WordPress will set the term_id and the term_taxonomy_id to the same value. If you've messed with the data, or applied your own imports / migrations, you might not get this same behaviour.
My initial thought was that it referenced another taxonomy (i.e. an FK from wp_term_taxonomy.parent to wp_term_taxonomy.term_taxonomy_id). ORMs like Corcel are built under this assumption. However, I've done some digging and most information seems to indicate that it actually references wp_terms.term_id.
In the case of Corcel, I think that this coincidentally works - WordPress will set the term_id and the term_taxonomy_id to the same value. If you've messed with the data, or applied your own imports / migrations, you might not get this same behaviour.
1 Answer
Reset to default 3WordPress doesn't use actual FOREIGN KEY constraints in MySQL. So, technically, wp_term_taxonomy.parent is merely an integer. However, what you've found is correct: it refers to a term in wp_terms by its term_id. But, as you've also noticed, the term_id and term_taxonomy_id should always be the same.
The reason they both exists is historical. Prior to WordPress 4.2, it was possible for taxonomy terms to belong to multiple taxonomies. So you could have a single term in wp_terms that corresponded to multiple rows in wp_term_taxonomies. WordPress 4.2 changed this so that terms can only belong to a single taxonomy. You can read some of the background on this change in this Make post from 2015.
These days you should only be using term_id to refer to terms programatically, and since a term's parent is also a term, the parent value refers to another term by its term_id.
Ideally the parent property would just be in the wp_terms table, but the existing structure will likely remain in place for backwards compatibility reasons.