Один источник данных в проекте: как убрать расходящиеся копии
Тем, кто собирает проект с ИИ и правит одну цену сразу в нескольких файлах
Метод поиска дублей и проверки пути от главной записи до экрана
6 мин
Цену поменяли в админке, а на другой странице и в сообщении бота осталась старая
У значения есть главное место хранения, остальные части проекта читают его оттуда
Как найти дубли цен, названий и статусов, назначить главный источник и проверить все места вывода после изменения.
Один источник данных означает простое правило: для каждого изменяемого факта известно, где хранится действующее значение. Это может быть запись базы, файл конфигурации или утверждённый справочник. Сайт, бот и отчёт показывают его по согласованному пути. Если цену можно исправить в админке, но для той же услуги есть отдельный текст в коде, перед вами две независимые версии. Рано или поздно они разойдутся.
Я начинаю с инвентаризации самого факта: название, цена, дата или статус. Затем ищу все места, где он отображается и меняется. Путь до ответа сотрудника проверяйте целиком: запаздывание синхронизации тоже может дать разные цены на одном заказе.
Как обнаружить лишнюю копию
Попросите ИИ найти механизм хранения и показа значения. Одной текстовой фразы для поиска мало. Начать можно с точной фразы, затем искать ключи, файлы базы и места вывода. После поиска вручную разделите совпадения: главный источник, временная переменная, историческая запись и случайная копия. Глобальная замена текста на этом этапе опасна: цена в старом договоре и цена действующего прайса имеют разный смысл.
rg -n 'Название услуги|цена услуги' app lib components content
rg -n 'price|amount|status|title' app lib componentsПути в командах условные, они зависят от вашего репозитория. Поиск покажет кандидатов, но не определит, какая цена действующая. В «Гражданине Мира» менеджер видит актуальную матрицу в CRM и больше не поддерживает свой список. Сверку точного значения надо делать по этой матрице и времени последней синхронизации.
Как выбрать главное место хранения
Начните с вопроса «кто меняет факт и когда изменение должно появиться». Если менеджер обновляет цену через админку, главный источник, вероятно, база, которую читает сайт и бот. Если факт меняется только при выпуске новой версии продукта, может подойти файл в репозитории. Если число приходит от внешнего сервиса, нужно явно назвать внешнюю систему и время последнего обновления. Не создавайте запасной файл «на случай недоступности» без срока жизни и проверки: он легко станет устаревшим параллельным источником.
Для каждого поля запишите смысл и владельца. «Цена» может означать цену первого шага, полную стоимость, сумму договора или оплату. Даже если числа одинаковые сегодня, это разные показатели. Отсутствующие значения тоже проверяйте отдельно; пример есть в статье о приёмке функции.
| Факт | Кто утверждает | Где главный источник | Где показывается |
|---|---|---|---|
| Текущая цена услуги | Ответственный за прайс | Рабочий прайс или база | Сайт, бот, смета |
| Статус записи | Расписание | Система записи | Личный кабинет, напоминание |
| Имя кейса | Редактор проекта | Справочник кейсов | Карточка и подпись снимка |
| Полученная оплата | Финансовый учёт | Подтверждённая запись платежа | Отчёт владельца |
Другой пример из моей работы: в КОСМЕТ_А данные сведены на одной базе, поэтому цифры сайта и управленческого отчёта не расходятся из‑за двух независимых копий. Записи и выручка при этом приходят из YCLIENTS; источник для каждого показателя нужно назвать отдельно. Если передача задержалась, показывайте время обновления и проверяйте состояние данных по правилу из разбора приёмки.
Как попросить ИИ исправить путь данных
Дайте задачу по конкретному факту и добавьте проверку пути данных. Условный пример: в небольшом сервисе сумма услуги хранится в базе, но карточка сайта и текст бота читают два отдельных массива. Попросите найти оба места, показать текущий путь данных и предложить изменение так, чтобы источник остался один. После исправления агент должен показать, где цена меняется и какие экраны получают новое значение. Проверку всех вызовов изменённой функции я описал в статье о приёмке правки ИИ.
Это условный пример, не описание клиентского проекта. В настоящей системе сперва проверьте правила округления, валюту, налоги и состав цены. Если сумма рассчитывается из нескольких полей, единственным источником может быть формула и входные значения. Готовое число тогда лишь результат расчёта. Не копируйте результат расчёта в другую таблицу без понятного обновления и контроля расхождений.
Как проверить изменение от начала до конца
Выберите тестовое значение, которое легко отличить от старого, и поменяйте его в разрешённом месте. Затем откройте все выходы: карточку, страницу услуги, ответ бота, отчёт. Проверьте и сохранение после перезапуска. Если один экран обновился позже, проверьте время последней синхронизации с главным источником. Цепочку сборки, выкладки и кеша разбираю в статье о размещении сайта.
| Шаг проверки | Вопрос | Ожидаемое свидетельство |
|---|---|---|
| Изменить факт | Правили главное место? | Одна сохранённая запись |
| Открыть интерфейсы | Все показывают новое? | Совпадающие значения |
| Перезапустить процесс | Значение осталось? | Данные прочитаны из хранилища |
| Проверить историю | Старые документы не переписались? | Историческая сумма сохранена |
После изменения источника сравните конкретное значение в каждом потребителе, включая сайт, бота и отчёт. Если один экран не обновился, проследите путь от записи до него и проверьте задержку обмена. Проверка должна закончиться совпадающими значениями или объяснённым расхождением. Фраза «данные синхронизируются» без срока результата не даёт.
Когда копия допустима
Исторический договор должен сохранять цену на дату подписания, даже если текущий прайс вырос. Копия базы для восстановления тоже нужна, но она не становится рабочим источником. Отчёт может хранить рассчитанный итог ради скорости, если известны исходные записи, способ пересчёта и время обновления. Для каждого такого случая подпишите назначение копии, иначе следующий разработчик примет её за главный справочник.
Не начинайте переделку сразу со всей системы. Выберите один факт, из‑за которого уже были ошибки, и пройдите его путь. Когда проверка работает, тем же методом займитесь другими ценами, датами и статусами. Так легче увидеть повторяющийся класс расхождений и убрать причину, а не править очередную страницу после жалобы клиента.
Частые вопросы
Нужно ли хранить все данные в одной таблице?
Нет. Источник правды назначается для каждого факта или процесса. Расписание и платежи могут жить в разных системах с понятной связью между ними.
Можно ли оставить цену в тексте страницы?
Если её меняют через админку, отдельный текст опасен. Страница должна брать действующую цену из того же источника либо явно относиться к историческому предложению.
Как найти дубли, если названия переменных разные?
Ищите не только слова, но и путь события: где значение вводят, сохраняют, преобразуют и выводят. Ручная проверка нескольких экранов помогает найти скрытые копии.
Что делать с кешем?
Укажите, когда он обновляется и как проверить версию на сервере. Порядок проверки всей доставки показан в статье о выкладке.
Как не сломать старые договоры?
Разделите текущий прайс и историческую сумму сделки. Последняя сохраняется вместе с договором и не переписывается при изменении каталога.
На обучении можем пройти один расходящийся показатель вашего проекта от места ввода до всех экранов. После такой проверки обычно становится понятно, какие копии удалять первыми.