Нормализовать старые дублирующиеся записи history.type_write='record'

[Denis_N]

При разборе #1403 обнаружено, что в таблице history есть старые дублирующиеся записи type_write='record'. Это не только ошибка отображения интерфейса: в БД действительно присутствуют соседние одинаковые записи истории для одного и того же изделия.

Предварительный анализ локальной копии БД показал:

• найдено 831 строгих соседних дублей type_write='record';
• затронуто 780 изделий;
• под строгим дублем понимается запись, которая идёт сразу после предыдущей записи того же UID по N, при этом у обеих записей type_write='record' и полностью совпадают смысловые поля: worker, order_from, whom_order, location, number_order, status, comment, bond, shelfdrawer;
• date и N при сравнении не учитываются, так как они различаются у самих дублей.

Основная масса дублей имеет вид:

• order_from='АДС', whom_order='АДС', location='work', без комментария;
• order_from='Склад', whom_order='АДС', location='work', без комментария.

Также есть редкие случаи с location=develop/stock/fk/isolator/nelikvid, несколько записей с комментариями и одна пара с пустыми order_from/whom_order/location.

Предлагается:

1. Сформировать отчёт по найденным группам дублей в виде «первая запись / дубль».
2. Для каждой группы оставлять первую запись по N.
3. Последующие записи считать кандидатами на удаление или архивную нормализацию.
4. Автоматически обрабатывать только безопасные случаи: соседние строгие дубли без комментария, без номера заказа, без bond, без shelfdrawer.
5. Случаи с комментариями, нестандартными location или большим разрывом по времени вынести на ручную проверку.
6. Перед изменением данных обязательно сделать резервную копию таблицы history.

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

[alx]

Replying to Denis_N:

Предлагается:

2. Для каждой группы оставлять первую запись по N.

А другие (не первые)?

3. Последующие записи считать кандидатами на удаление или архивную нормализацию.

Во-первых, поясни, пожалуйста, почему (или для чего) ты предлагаешь считать их кандидатами на удаление. Непонятно, зачем удалять записи из истории (если, допустим, выяснится, что эти записи - результат действий пользователя, а не какой-нибудь ошибки в коде)... Обрати внимание, что записи, показанные в описании тикета #1403, занесены с разницей в 12 секунд. Сложно представить, что запрос так долго выполнялся бэкендом. Это больше похоже на осознанное занесение пользователем двух похожих записей...

Во-вторых, непонятно, что такое "архивная нормализация". Не знаю как @san, а я не знаком с таким терином...

4. Автоматически обрабатывать только безопасные случаи: соседние строгие дубли без комментария, без номера заказа, без bond, без shelfdrawer.

Совершенно непонятное предложение, так как не сказано, о какой обработке идет речь... О переведении текста в верхний регистр? :)

5. Случаи с комментариями, нестандартными location или большим разрывом по времени вынести на ручную проверку.

Проверку чего?

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

Поясни, пожалуйста, что ты называешь "техническими дублями". Это когда пользователь прислал один запрос, а в базу занесено две (или более) записи? Если так, то откуда известно, что такие технические дубли вообще имели место? Ты нашел ошибку в коде, которая приводила к такому поведению? В комментариях к тикету #1403 я ничего об этом не вижу...