В молодом проекте можно увидеть, как несколько разных функций хранит один и тот же кусочек данных каждый в своей таблице - потому что эти функции разрабатывались разными людьми, в разное время, без общей картины. Учебник ужаснулся бы: “избыточное хранение, нарушение нормальных форм, ай-ай-ай”. А на практике? Работает себе и ладно. Когда-нибудь потом сделают миграцию и объединят, если это реально мешает или провоцирует баги (хотя в этом случае хочется задать вопрос - а куда вы дели тесты?). А может и не сделают - потому что дополнительный столбец в таблице отчётов никому жить не мешает, а код вокруг него давно устаканился. “Это моя проблема или сервиса?” спросите вы. В эволюционирующем сервисе это не проблема, потому что не создает проблем в доставке и поддержке и может быть легко исправлено. Это исправится, не нужно по этому поводу лить слёз.
Это не призыв плодить бардак в схеме данных. Но правда такова: простая, даже если избыточная, схема часто лучше сложной идеальной модели. Если какая-то новая сущность легко ложится в виде отдельной таблицы - сделайте таблицу, не мучайте существующую сложными связями. Пусть будут некоторые дубли - с хорошими тестами вы не потеряете целостность, а жить станет проще.