Половина проблем в собранных данных — это не пропуски, а дубли.

Половина проблем в собранных данных — это не пропуски, а дубли.

Одна и та же сущность приезжает несколько раз: с разных страниц, из разных разделов, при повторном обходе после сбоя. Если у записи нет устойчивого ключа, база тихо распухает, а любые подсчёты становятся неверными.

Ключ стоит выбирать по принципу «что у этой сущности не меняется». Внутренний идентификатор источника — лучший вариант. Адрес страницы — приемлемый, но с оговорками: у одной сущности бывает несколько адресов, а метки отслеживания в конце превращают один адрес в десяток.

Если идентификатора нет, ключ собирают из нескольких полей, которые вместе почти уникальны. При этом важно нормализовать значения перед сравнением: убрать лишние пробелы, привести регистр, отбросить служебные приставки.

Отдельный случай — сущность изменилась. Тут решают заранее: перезаписывать, хранить версии или хранить только последнее состояние с датой. Решение принимается один раз, а переделывается тяжело.

Дубли дешевле не пускать, чем потом вычищать.