The MH_Triangulate table stores triangulated DNA segments — regions where you and two of your MyHeritage matches all overlap on the same chromosome. Each row is one such intersected segment, recorded from the perspective of one of your kits (kitid) and a pair of matches (guid1, guid2).
| Column | Type | Description |
|---|---|---|
| Id | int (PK) | Auto-incrementing primary key |
| kitid | string | Your kit ID — the test whose matches are being triangulated. Indexed. |
| guid1 | string | First of the two matches in the triangulated pair |
| guid2 | string | Second of the two matches in the triangulated pair |
| chromosome | int | Chromosome number the triangulated segment is on |
| cm | decimal | Length of the triangulated segment in centimorgans |
| start | int | Start physical position of the segment (base-pair coordinate) |
| end | int | End physical position of the segment (base-pair coordinate) |
| snps | int | Number of SNPs spanned by the segment |
| startrs | string | RSID at the segment’s start boundary |
| endrs | string | RSID at the segment’s end boundary |
Rows are written by AddMH_Triangulation during the triangulation gather stage. For each intersected segment between two matches, the code stores kitid (your kit), the two match IDs, and the segment details (chromosome, cM, positions, SNP count, and boundary RSIDs). Each segment is stored both ways — once as (guid1, guid2) and once reversed as (guid2, guid1) — so a lookup from either match finds it. Inserts are de-duplicated on the combination of kitid, guid1, guid2, chromosome, and start. A schema migration prefixes legacy kitid values with “D-” so they match the ID format used elsewhere.
kitid, guid1, and guid2 correspond to the ID values stored on match rows.triSegments count there is summarised from triangulated segments like these.