#поразмыслим Проблема "дрейфующих" первичных ключей при объединении данных из разных систем 🔸 Допустим, есть 10 разных однотипных источников о клиентах, из которых нужно получить по 1 записи о каждом "реальном" клиенте. Для решения такой задачи есть процессы "матчинга" и "мёржинга". В первом случае сопоставляем строки между собой и формируем "кластер" записей. Во втором — схлопываем в одну "золотую" запись, выбирая самый полный набор атрибутов из самых достоверных источников. Я уже писал выше про ``splink`` как один из python пакетов, на которых можно такое реализовать. 🔸 Но что делать с ключами? Если выбирать "главную" запись в кластере и делать, например, расчёт хэша на основе её хэша, на первый взгляд всё хорошо. Если добавляются новые записи, они линкуются к той же строчке. Если эти записи влияют на атрибуты, мы обновляем "мастер запись" на основе hash_diff значения. 🔸 А что если эта "главная" запись удалится, а остальные — продолжат формировать кластер? Как сохранить итоговый ключ, чтобы сохранить историю изменений? И на основе чего его можно считать, если у нас нет надёжного набора бизнес-ключей, по которым мы можем гарантировать, что эти записи — об одном человеке. И запись из любого источника может удалиться или "перенестись" в другой кластер при изменении правила матчинга. Более подробный пример будет в комментах внутри Ставь 🐘 или ⭐️, если хочешь больше сеньорных постов