Кейс с артистами: дедупликация пользователей в базе данных и сохранение связанных с ними записей

[Akina]

Прочитал.. Если откровенно - этот процесс надо бы назвать словом "продрался". Ну просто-таки поток неструктурированного сознания. Даже понимая, о чём речь, приходится потратить много внимания, чтобы полностью понять сделанное. И в конце концов оказывается, что статья посвящена решению ну абсолютно стандартной задачи по поиску компонент связности.

В процессе разработки мы протестировали два алгоритма для поиска таких дублирующихся групп

А почему только эти? тем более в PostgreSQL, где есть несколько альтернативных подходов, для которых в СУБД имеются достаточно эффективные средства.

Здесь важен не точный синтаксис SQL, а скорее сам процесс.

Для того, чтобы понять этот самый "скорее сам процесс", синтаксис - ВАЖЕН. Та ерунда, которая приведена как код, не имеет вообще никакого смысла - во-первых, из-за интерференции имён полей, что при отсутствии алиасов превращает код в бардак, во-вторых, из-за отсутствия исходных структур хранения данных. Плюс некоторые тонкости, важные для решения задачи, просто не озвучены - например, причины использования то UNION ALL, то UNION DISTINCT.