Почему базы данных почти всегда живут дольше кода приложений
Разбираем, почему базы данных переживают переписывание приложений: роль данных как актива, стабильность схемы, интеграции, риски миграций и практики эволюции.
Код меняется, данные остаются: суть феномена
Код приложений почти неизбежно меняется быстрее, чем данные. Функции переписывают, интерфейсы обновляют, команды и подрядчики сменяются, языки и фреймворки выходят из моды. А вот записи о клиентах, платежах, договорах и остатках должны сохраняться годами — потому что на них завязаны бизнес‑решения, отчётность и ответственность.
«Логика» против «памяти» системы
Упрощённо: код — это логика, то есть правила обработки и представления информации. Данные — это память системы: факты, накопленные со временем. Логику можно заменить (и часто это даже полезно), но память нельзя «переизобрести» без потерь: её нужно переносить, проверять, согласовывать и защищать.
Когда меняется код, чаще всего меняются способы:
- как пользователь вводит информацию;
- как система рассчитывает показатели;
- как данные отображаются и ищутся.
Но сами факты — кто что купил, кому что выставили, какие статусы были у сделки — остаются значимыми и через год, и через пять.
Пара бытовых примеров
В CRM карточки клиентов и история коммуникаций копятся годами. Можно заменить приложение, переделать воронку, добавить новые поля — но прошлые контакты и сделки всё равно нужны для анализа, поддержки и повторных продаж.
В бухгалтерии ситуация ещё жёстче: проводки, счета, акты и платежи должны быть воспроизводимыми и проверяемыми задним числом. Интерфейс можно обновить, логику расчётов уточнить, но данные обязаны пережить любые «ремонты» системы.
Эта статья — не про то, «какая СУБД лучшая». Она про причины долговечности баз данных и практики, которые помогают менять код безопасно, не ставя под угрозу накопленные данные.
Данные как актив, а не деталь реализации
Приложение часто воспринимают как «продукт», а базу — как техническую подкладку. На практике всё наоборот: код — это способ работать с данными, а сами данные — актив компании. В них зашиты история решений, юридические обязательства, отношения с клиентами, факты операций и основа для аналитики.
Что именно делает данные активом
Данные — это не только текущие записи «как есть», но и накопленная ценность:
- История и доказуемость: кто что купил, когда был подписан документ, какие были изменения статуса.
- Обязательства: требования регуляторов, сроки хранения, возможность аудита.
- Аналитика и стратегия: метрики, сегментации, прогнозы, обучение моделей.
Если переписать сервис можно за месяцы, то потеря части данных способна стоить годы доверия, штрафов и невозможности восстановить бизнес-контекст.
Почему перенос со временем дорожает
Чем дольше система работает, тем больше она «обрастает» смыслом: появляются редкие кейсы, исключения, особые статусы, ручные исправления, связи между сущностями. При миграции важно перенести не только строки, но и значение этих строк — иначе новая система начинает выдавать правильные ответы на неправильные вопросы.
Данные нужны сразу многим
Данные почти никогда не принадлежат одному приложению. Ими пользуются финансы, поддержка, маркетинг, BI, интеграции с партнёрами, внутренние отчёты. Поэтому база быстро становится точкой согласования интересов: изменить модель — значит затронуть процессы множества команд.
Именно поэтому обычно дешевле и безопаснее переписать код вокруг базы, чем «просто перенести всё» и рискнуть тем, что компания копила годами.
Много потребителей: база как центр интеграций
Часто база данных незаметно превращается в общий «узел» для нескольких приложений. Один сервис пишет заказы, другой читает их для поддержки, третий считает бонусы, четвёртый строит отчёты. И даже если формально есть API, на практике все завязаны на одни и те же сущности: клиент, заказ, платеж, статус.
Как вокруг БД вырастает «паутина»
Интеграции появляются быстрее, чем успевают их оформить в документации. К базе подключают:
- отчёты для финансов и операционного контроля;
- регулярные выгрузки в партнёрские системы;
- BI-инструменты и витрины данных;
- скрипты сверки, антифрод, аудит;
- «временные» импорты/экспорты, которые потом живут годами.
Каждый новый потребитель добавляет ценность данным — и одновременно увеличивает цену изменений.
Контракт на данные обычно берегут сильнее, чем код
UI можно переписать, бэкенд — заменить, даже язык программирования — поменять. Но если при этом ломается привычная структура данных (или смысл полей), страдают все: отчёты перестают сходиться, выгрузки начинают отдавать пустые значения, партнёр получает «не те» статусы, бизнес теряет доверие к цифрам.
Поэтому в зрелых системах схема и семантика данных становятся своего рода контрактом предметной области. Её меняют осторожно: добавляют новые поля вместо удаления старых, вводят новые таблицы параллельно существующим, делают переходы поэтапно.
Чем больше потребителей, тем стабильнее интерфейс
Получается эффект «сети»: каждый новый интегратор делает базу более «долгоживущей», потому что уменьшает готовность команды ломать совместимость ради удобства кода. В итоге приложение меняется чаще, а база остаётся центром, вокруг которого перестраивают всё остальное — так, чтобы данные продолжали быть понятными и сопоставимыми во времени.
Схема как «контракт» предметной области
Схема базы данных — это не просто техническая заготовка «куда складывать поля». Она фиксирует, как бизнес видит мир: какие сущности существуют (клиент, заказ, платёж), какие у них свойства, как они связаны и какие правила считаются истинными всегда.
Явное описание предметной области
В коде предметная область часто «размазана» по сервисам, DTO, валидаторам и UI-формам. Инварианты могут быть спрятаны в ветках условий или вовсе держаться на дисциплине команды. Схема же делает модель явной: таблицы и связи задают словарь домена, а ограничения превращают часть правил в проверяемые факты.
Например, внешний ключ показывает, что заказ не может существовать без клиента. Уникальный индекс закрепляет, что у пользователя один email. CHECK-ограничение или перечисление значений фиксирует, что статус заказа ограничен согласованным набором.
Таблицы, связи и ограничения фиксируют смысл
Когда смысл закреплён в структуре данных, он становится общим для всех потребителей. Любое приложение, отчёт или интеграция читают одну и ту же «истину» — не интерпретации разных команд. Это и делает схему похожей на контракт: она задаёт ожидания, которым должны следовать все стороны.
Почему изменения модели требуют больше согласований
Изменить код обычно можно локально: обновить один сервис и выкатить новую версию. Изменить схему сложнее, потому что её «подписантов» больше:
- несколько приложений и фоновых задач;
- отчёты и BI-инструменты;
- внешние интеграции и выгрузки;
- процессы поддержки и ручные операции.
Даже небольшая правка (переименование столбца, изменение типа, новая обязательность поля) может сломать чужие запросы или ожидания. Поэтому изменения схемы требуют согласования, планирования миграций и периода совместимости — фактически это управление контрактом, а не просто рефакторинг.
Эволюция схемы и обратная совместимость
Схема базы данных редко остаётся неизменной: появляются новые продукты, отчёты, интеграции, требования регуляторов. Но именно из‑за долгой жизни данных любое изменение схемы должно быть «вежливым» к существующим потребителям — старым версиям приложений, BI‑выгрузкам, скриптам поддержки и внешним системам.
Что ломает совместимость чаще всего
Самые безопасные изменения обычно добавочные: новое поле, новая таблица, новый индекс. Они не мешают старому коду — он просто не знает о новинках.
А вот удаление, переименование или изменение смысла поля — типичные источники аварий. В базе это похоже на смену адреса у дома, где у десятков людей записан старый: даже если «переезд» логичен, все должны обновиться одновременно, что почти никогда не происходит.
Практика «расширяй, не ломай»
Чтобы база «жила долго», полезно придерживаться подхода expand-only на переходных периодах:
- добавлять новое поле/таблицу рядом со старым;
- некоторое время поддерживать оба варианта;
- постепенно переводить чтение и запись на новую структуру;
- только потом удалять старое — и то после измеримого периода без обращений.
Миграции как часть релиза (вперёд и назад)
Миграции должны быть таким же артефактом релиза, как и обновление приложения: с проверками, порядком выполнения и планом отката. На практике откат схемы сложнее отката кода, поэтому безопаснее проектировать миграции так, чтобы можно было временно «откатиться» приложением, не потеряв новые данные (например, хранить значения в старых колонках параллельно).
Версионирование схемы и переходные периоды
Полезно явно версионировать изменения: фиксировать номер миграции, дату, владельца, и вводить переходные окна, когда поддерживаются две версии представлений/контрактов. Это снижает риск «единого большого переключателя» и позволяет базе эволюционировать без болезненных остановок.
Риски миграций: переместить данные сложнее, чем код
Код можно переписать, откатить, переиспользовать модулями. С данными так не получится: они единственные, накоплены годами и часто содержат «следы реальности», которые не описаны ни в одном README. Поэтому миграция почти всегда рискованнее, чем замена приложения, даже если новая система написана идеально.
Перенос данных — это не «скопировать таблицы»
Объём — только первая проблема. Дальше выясняется качество: пропуски, неконсистентные значения, старые «временные» поля, которые стали постоянными. Встречаются дубликаты (один клиент заведён пять раз под разными e-mail), разные форматы (даты строкой, телефоны без кода страны), и негласные правила («если поле пустое, значит…»), на которых завязана отчётность.
Даже простое сопоставление справочников превращается в проект: что делать с удалёнными сущностями, слиянием записей, устаревшими статусами.
Простой и потери: цена окна миграции
Миграция требует окна простоя или сложной синхронизации. Если система должна работать без остановки, появляется «двойная запись», репликация, очередь событий, сверки — и каждый слой может дать рассинхронизацию.
Проверки тоже не бесплатны: контрольные суммы, выборочные сравнения, повторные прогоны. На практике риск не в том, что «данные потеряются», а в том, что потеряются незаметно: один процент ошибок потом превращается в недели разборов и недоверие пользователей.
Историчность: то, что ломается первым
Сложнее всего переносить историю: цепочки статусов, аудиты изменений, комментарии, события, временные срезы («как было на конец квартала»). Новая модель данных может не иметь места для этих деталей, а бизнес — продолжать на них опираться (споры с клиентами, compliance, аналитика).
Именно поэтому переписать код часто проще: код — это логика, а данные — это память компании, и цена ошибки в этой памяти намного выше.
Надёжность, резервирование и требования к хранению
База данных обычно «прирастает» операционной зрелостью: вокруг неё выстраивают процессы, которые обеспечивают предсказуемость и восстановление. И чем больше в БД вложено в надёжность и соответствие требованиям, тем меньше желания (и возможностей) её быстро заменить — слишком много зависит не от кода, а от дисциплины хранения.
Резервные копии и восстановление: RPO/RTO как обязательные требования
Для приложений можно чаще позволить себе «пересобрать и выкатить заново». Для данных — нет. Почти везде со временем появляются формальные цели восстановления:
- RPO (сколько данных допустимо потерять)
- RTO (за какое время сервис должен вернуться в строй)
Под эти показатели настраиваются бэкапы, процедуры восстановления, регулярные тесты восстановления и отдельные среды для проверки.
Журналы, репликация, безопасность
Долгоживущая БД редко ограничивается «одним сервером». Появляются журналы транзакций, репликация для отказоустойчивости и чтения, строгий контроль доступа по ролям. Добавьте шифрование (на диске и/или на уровне соединений), управление ключами, ротацию секретов — и база превращается в критический компонент, который трудно «переехать» без потери гарантий.
Соответствие требованиям: хранение, аудит, права
Требования бизнеса и регуляторов часто закрепляют базу как систему записи: сроки хранения, неизменяемые журналы аудита, разграничение прав, доказуемость действий пользователей. Эти обязательства живут годами и переживают несколько поколений приложений.
Почему зрелость делает БД «неподвижной»
Когда вокруг БД выстроены мониторинг, регламенты инцидентов, плановые переключения, отчётность по доступности и безопасности, цена смены технологии становится не столько технической, сколько организационной. Поэтому код обновляют чаще — а базу берегут как фундамент.
Стандарты и экосистема: почему БД проще «пережить»
Одна из причин, почему базы данных живут дольше приложений, — не только «железобетонность» хранения, а стандарты и огромная экосистема вокруг. Код приложения часто привязан к конкретному фреймворку, версии языка, сборщику, библиотекам и даже привычкам команды. База же обычно опирается на более устойчивые договорённости.
SQL и реляционная модель как «долгая совместимость»
Реляционная модель и SQL дают редкую вещь: переносимость знаний. Если вы понимаете таблицы, связи, индексы и базовые конструкции SQL, вы сможете работать с разными СУБД и разными эпохами проектов. Синтаксис и функции отличаются, но фундамент остаётся узнаваемым — и это резко снижает «стоимость» смены приложения вокруг базы.
Инструменты есть почти для всего
Вокруг популярных СУБД существует широкий выбор клиентских драйверов и коннекторов, ORM, ETL/ELT-инструментов, BI-систем и утилит администрирования. Если одно приложение уходит, другое почти наверняка сможет подключиться к тем же данным без изобретения собственного протокола и без переписывания половины инфраструктуры.
Типичный эффект: бизнес меняет CRM или витрину, а данные (и подход к работе с ними) остаются — потому что их можно читать, выгружать, проверять, интегрировать стандартными средствами.
Контраст с «модой» в коде
Фреймворки и библиотеки в приложениях меняются быстрее: то, что было «каноном» пять лет назад, сегодня может оказаться неподдерживаемым. У базы тоже бывают обновления и новые фичи, но база чаще «переживает» эту смену технологических трендов именно благодаря стандартам и совместимости инструментов.
Логика в базе: когда это продлевает жизнь БД
Иногда долгоживущая база данных выигрывает от того, что часть правил «живет» рядом с данными. Хранимые процедуры, триггеры и представления позволяют закрепить ключевые инварианты предметной области на уровне СУБД — там, где их сложнее обойти случайной ошибкой в приложении.
Что обычно уместно переносить в БД
В БД хорошо чувствуют себя правила, которые должны соблюдаться всегда, независимо от того, кто пишет в таблицы: основное приложение, админская утилита, интеграция или пакетная загрузка.
Это могут быть:
- ограничения целостности (FK, CHECK), уникальность, запрещённые состояния;
- триггеры для аудит-логов, корректной денормализации, поддержания счетчиков;
- представления (views) как стабильный «срез» данных для отчётов и внешних потребителей;
- хранимые процедуры для критических операций, где важны атомарность и единый сценарий обновления.
Плюсы: единые правила и меньше «разъезжающихся» реализаций
Когда правила закреплены в БД, они переживают переписывание сервисов и смену фреймворков. Новое приложение может поменяться полностью, но база продолжит гарантировать целостность. Дополнительный плюс — производительность в узких местах: тяжёлые операции иногда дешевле выполнить «на месте», не гоняя данные по сети.
Минусы: скрытое поведение и сложнее инженерная дисциплина
Логика в БД повышает связность: приложение может неожиданно зависеть от триггера или процедуры, о которой не знают разработчики. Тестирование тоже сложнее: нужны интеграционные тесты, миграции должны версионировать не только схему, но и функции/процедуры.
Как не превратить БД в монолит
Практичный баланс — держать в БД только «законы данных» (целостность, аудит, критические транзакции), а бизнес-процессы и оркестрацию оставлять в приложении.
Помогают простые правила: документировать триггеры и процедуры рядом с миграциями, версионировать их как код, иметь явные контракты (например, через views), и регулярно проверять «неявные эффекты» в тестовой среде перед релизом.
Архитектура вокруг БД, чтобы код менялся безопасно
Долгая жизнь базы — это не приговор приложению, если вокруг данных построены «буферы», которые позволяют переписывать код по частям. Идея простая: приложения должны зависеть не от таблиц напрямую, а от понятных, ограниченных контрактов чтения и записи.
Слои доступа: меньше «прямых проводов» к таблицам
Первый защитный слой — единый доступ к данным через репозитории или сервисный API. Вместо того чтобы десятки модулей формировали SQL «как получится», запросы и правила работы с данными живут в одном месте.
Если рядом есть внешние системы, полезен анти-коррупционный слой: он переводит чужие форматы и термины в вашу предметную модель. Тогда интеграция меняется — а ядро данных остаётся стабильным.
Контракты на чтение/запись
Контракт — это обещание, что запись делается определённым способом, а чтение отдаёт определённую структуру. Практически это может быть:
- строго ограниченный набор команд на запись (например, через сервис или хранимые процедуры — по ситуации);
- чтение через представления (views) или отдельные «витрины» данных;
- запрет на прямой доступ к таблицам для сторонних потребителей.
Так вы защищаете схему от случайных зависимостей: изменение колонки в таблице не должно неожиданно «уронить» отчёт или интеграцию.
Паттерны для постепенной замены
Упрощённый CQRS помогает разделить «как записываем» и «как читаем»: запись остаётся строгой и проверяемой, а чтение можно оптимизировать под разные экраны и отчёты.
Событийная модель (например, публикация событий о фактах: «заказ создан», «оплата получена») снижает число точек прямой интеграции с БД. А для замены компонентов работает стратегия постепенного переключения: новый сервис начинает читать/писать через те же контракты, затем трафик переводится поэтапно.
Результат: приложение можно менять быстро, не трогая фундамент — данные и существующие интеграции.
Примечание про быстрые изменения продукта
Если вы используете платформы, которые ускоряют разработку (например, TakProsto.AI — vibe-coding подход для создания веб/серверных/мобильных приложений через чат), этот принцип становится ещё важнее: интерфейсы и сервисы можно менять чаще, чем прежде, а вот модель данных в PostgreSQL всё равно должна эволюционировать аккуратно и обратно совместимо.
На практике помогают режим планирования (чтобы заранее зафиксировать контракты данных), а также снапшоты и rollback — как дополнительная страховка при изменениях схемы и логики доступа к данным.
Когда долговечность превращается в проблему
Долгая жизнь базы данных — это плюс, пока она остаётся управляемой. Но со временем «центральность» БД может превратиться в тормоз: любые изменения становятся дорогими, риск — высоким, а знания о системе — размытыми.
Типичные симптомы
Часто проблема видна по быту команды:
- Один общий «большой» инстанс на всё (прод, отчёты, интеграции, эксперименты) с непредсказуемыми нагрузками.
- Ручные изменения в продакшене: «поправили столбец через консоль», «удалили пару строк руками».
- Миграций либо нет, либо они не воспроизводимы: разные окружения живут с разными версиями схемы.
Как выглядит технический долг в БД
Долговечность усиливает накопление долга:
- Слабая или устаревшая документация: непонятно, какие таблицы критичны, а какие — исторический мусор.
- Нет владельцев данных: никто не отвечает за качество, смысл полей и правила изменения.
- Хаос прав доступа: лишние суперпользователи, неясные роли, интеграции с «вечными» учётками.
Метрики здоровья, которые показывают реальность
Чтобы понять масштаб, полезно отслеживать простые показатели:
- Время от идеи до безопасного изменения схемы (и до выката во все окружения).
- Частота инцидентов, связанных с данными/схемой (ошибки миграций, блокировки, деградация запросов).
- Качество данных: доля дублей, процент NULL там, где их не должно быть, расхождения между источниками.
Мини-чек-лист: что исправлять в первую очередь
- Запретить ручные изменения: всё через миграции и ревью.
- Назначить владельцев ключевых наборов данных и описать «что считается истиной».
- Привести права в порядок (принцип минимальных привилегий, ротация секретов).
- Зафиксировать контракты: описание таблиц/полей, критичные зависимости, правила совместимости.
- Наладить наблюдаемость: метрики, алерты, журнал изменений схемы.
Если эти базовые вещи не сделаны, БД действительно «живёт дольше кода» — но цена этой долговечности начинает расти быстрее пользы.
Практики, которые помогают базам жить долго — без боли
Долгая жизнь базы данных не случается «сама собой». Её продлевают не героические миграции по ночам, а дисциплина вокруг изменений: кто принимает решения, как фиксируются договорённости и как обеспечивается совместимость.
1) Владелец данных и правила изменения схемы
Назначьте владельцев доменов данных (например, «клиенты», «заказы», «платежи») и договоритесь о простых правилах:
- кто утверждает изменения таблиц/полей и семантики;
- какие изменения считаются «ломающими» (удаление поля, смена смысла, ужесточение ограничений);
- какие метрики качества данных критичны (уникальность, полнота, допустимые значения).
Это снижает хаос, когда разные команды трактуют одно и то же поле по‑разному.
2) Миграции как продукт: ревью, каталог и документация
Сделайте изменения схемы воспроизводимыми и проверяемыми:
- миграции хранятся в репозитории и проходят ревью (как обычный код);
- есть каталог данных/глоссарий: что означает поле, откуда берётся, кто использует;
- документация фиксирует «контракты» и примеры запросов.
Даже минимальный каталог (таблица + описание + владелец + потребители) резко ускоряет поддержку.
3) Планирование совместимости: депрекейты и параллельная работа
Хороший подход — менять в два шага: сначала добавить новое (поле/таблицу), поддерживать оба варианта, затем постепенно отключать старое.
Практики:
- депрекейт с датой отключения и списком потребителей;
- период параллельной работы (dual-write/dual-read) там, где нужно;
- мониторинг использования старых полей перед удалением.
Где здесь может помочь TakProsto.AI
Если вы собираете или модернизируете внутренние системы в TakProsto.AI (React на фронтенде, Go + PostgreSQL на бэкенде; для мобильных — Flutter), полезно сразу закладывать «долгую жизнь» данных:
- фиксировать контракты данных до начала активных изменений через planning mode;
- хранить миграции и изменения схемы так же строго, как изменения приложения;
- использовать снапшоты и rollback как практичный механизм снижения риска при релизах.
Плюс — при необходимости можно экспортировать исходный код и продолжить развитие вне платформы, не теряя контроль над схемой и данными.
Дальше почитать
- Про стратегии миграций и откаты: /blog/migrations
- Про качество и наблюдаемость данных: /blog/data-quality
FAQ
Почему базы данных обычно живут дольше кода приложений?
Потому что код — это «логика» (как обрабатывать и показывать), а данные — «память» (факты о клиентах, платежах, договорах). Логику можно заменить и откатить, а потерянные/искажённые факты часто невозможно восстановить без последствий для бизнеса, отчётности и ответственности.
Какие изменения схемы чаще всего приводят к поломкам?
Почти всегда ломают совместимость:
- удаление или переименование столбцов/таблиц;
- изменение смысла поля (семантики) без явного переходного периода;
- ужесточение ограничений (NOT NULL, FK, CHECK) без подготовки данных;
- изменение типов (строка → дата/число) без обратимой миграции.
Самые безопасные изменения обычно «добавочные»: новые поля, таблицы, индексы.
Как безопасно развивать схему, не ломая старых потребителей?
Работает подход «расширяй, не ломай»:
- Добавьте новое поле/таблицу рядом со старым.
- Поддерживайте оба варианта (dual-read/dual-write — где нужно).
- Переведите потребителей поэтапно.
- Удаляйте старое только после периода, когда обращений к нему нет (и это измерено).
Так вы избегаете «единого большого переключателя», который редко проходит без инцидентов.
Почему миграция данных обычно сложнее переписывания сервиса?
Миграция — это не копирование таблиц, а перенос смысла:
- качество данных: дубли, пропуски, «негласные правила», разные форматы;
- историчность: статусы, аудит, события, «срезы на дату»;
- непрерывность работы: простои или сложная синхронизация;
- проверяемость: сверки, контрольные суммы, выборочные проверки.
Чаще всего риск не в «полной потере», а в незаметных ошибках, которые проявятся в отчётах и поддержке.
Что обязательно планировать перед переносом данных?
Чтобы минимизировать риски, заранее готовят:
- инвентаризацию потребителей (приложения, BI, выгрузки, скрипты);
- карту соответствий (mapping) и правила обработки исключений;
- план простоя или стратегию синхронизации (репликация/очередь/двойная запись);
- набор проверок (row counts, контрольные суммы, ключевые отчёты);
- план отката (как минимум — откат приложения без потери новых данных).
И отдельно — тестовый прогон на копии прод-данных.
Почему изменения базы требуют больше согласований, чем изменения кода?
У неё много «подписантов»: сервисы, отчёты, BI, партнёрские интеграции, ручные операции поддержки. Схема и семантика полей становятся общим контрактом: если вы меняете поле, вы меняете ожидания сразу у десятков потребителей.
Практика: перед ломаюшими изменениями вводите депрекейт (с датой отключения) и список владельцев/потребителей, которых нужно перевести.
Как база данных превращается в «узел» для многих систем и почему это важно?
БД часто становится центром интеграций: один пишет заказы, другой читает для поддержки, третий строит отчёты. Даже если есть API, в реальности появляются «временные» подключения и выгрузки, которые живут годами.
Полезные меры:
- запрет прямого доступа к таблицам для сторонних потребителей;
- чтение через представления (views) или витрины;
- фиксированный набор команд на запись (через сервис/процедуры — по ситуации).
Когда имеет смысл переносить часть логики в базу (триггеры, процедуры, views)?
Уместно хранить в БД то, что должно соблюдаться всегда, независимо от клиента записи:
- ограничения целостности (FK, UNIQUE, CHECK);
- аудит-логи и неизменяемые журналы;
- представления для стабильного чтения;
- критические атомарные операции, где важна транзакционность.
Не стоит переносить в БД сложную оркестрацию бизнес-процессов: это повышает связность и усложняет тестирование.
Какие требования к надёжности делают БД особенно «долгоживущей»?
Как минимум нужны измеримые цели восстановления:
- RPO — сколько данных допустимо потерять;
- RTO — за какое время система должна восстановиться.
Под это настраивают бэкапы, репликацию, права доступа, шифрование, регулярные тесты восстановления. Со временем вокруг БД появляется операционная «зрелость», которую сложно быстро воспроизвести на новой технологии.
Как понять, что долговечность БД стала проблемой, и что делать в первую очередь?
Типичные признаки:
- ручные правки в продакшене вместо миграций;
- разные версии схемы на окружениях;
- хаос с правами и «вечные» учётки интеграций;
- нет владельцев данных и описания смысла полей.
Практический минимум:
- Все изменения — только через миграции и ревью.
- Назначить владельцев ключевых доменов данных.
- Зафиксировать контракты и депрекейты.
- Наладить наблюдаемость (метрики, алерты, журнал изменений).
В качестве продолжения подойдут материалы: /blog/migrations и /blog/data-quality.