Кнопка очистки данных: почему её так сложно сделать
Время от времени среда разработки сильно разъезжается с промышленной. А чем больше разрыв, тем дороже разработка и поставка доработок: ты тестируешь не то, что в проде, и ловишь сюрпризы в самый неподходящий момент.
Сократить разрыв можно, если поднять копию прода. Идея понятная. Но встаёт вопрос: что делать с данными?
Реальные данные в тестовом контуре, это разговор с ИБ, который ты проиграешь. Значит, вариантов два: обфускация или зачистка.
Обфускация. История понятная, но если в системе сотни таблиц с миллионами записей, то это не слишком экономно. Ни по времени, ни по ресурсам.
Зачистка. Тоже понятно. Но, как показывает опыт, гладко проходит не со всеми системами. И вот почему.
Прямое удаление из БД работает не всегда. Помимо физического удаления записи, могут требоваться дополнительные «приседания», порой в самых неочевидных местах.
Не все данные нужно удалять. Данные делятся на рабочие, справочные и технические. Справочные из охвата чаще всего исключаются, например, потому что элементы справочника могут быть задействованы в бизнес-логике как значения по умолчанию. Удалишь – сломаешь логику.
Порядок удаления важен. Технические данные могут ссылаться на рабочие. Удаляешь рабочие, ловишь ошибки целостности. Значит, нужен порядок, и он не всегда очевиден.
Возможность отключать бизнес-логику должна быть by-design. Представь: удаляешь данные одного типа, а они не удаляются, потому что срабатывает валидация на данных, напрямую с текущими не связанных. И ты сидишь и думаешь, при чём тут вообще они.
Неоднозначные ошибки не помогают найти корень. Удаляешь объект, а в ответ: «Не удалось удалить объект». Занавес. Что не так, неясно. И начинается археология.
Вывод
«Кнопка очистки данных» звучит как одна фича. На деле это целый пласт работы: правила обхода таблиц, зависимости, отключаемая бизнес-логика, внятные ошибки и договорённости с ИБ. И делать это нужно до того, как копия прода понадобится, а не в момент, когда она уже горит.
Можно относиться к очистке данных как к DELETE FROM без WHERE. А можно, как к задаче, где важен порядок удаления, зависимости и то, что будет, если ошибиться. Первый взгляд дешевле ровно до момента, когда что-то ломается.
Убежден, что список сложностей не полон. Кто уже проходил это, расскажите, как решали: обфускацией, зачисткой или гибридом? Где споткнулись?
