Нормальные формы БД

Я помню, что их три, и примерно два дня до собеса и два дня после помню, что какая значит. Помню, что суть в том, что все хранится один раз и именно там, где надо. Дальше у нас идут отношения 1-N, 1-1 и N-N, и как рубить второе с помощью вспомогательной таблицы (обычно поясняется на классическом примере авторов и книг).
Вся вот эта схематизация данных (равно как и строгая типизация в ЯП, но я отвлекаюсь) помогает, в том числе, заострить внимание на ценности данных. Что это самое важное во всей системе. Интернет, до кучи, изобилует историями о том, как пришедшую к успеху систему на какой-нибудь несхематизированной MongoDB потом приходится долго и нудно схематизировать, а то и переводить на какой-нибудь замшелый постгрес, потому что консистентность и производительность.
Но о чем, на самом деле, я. Вот у нас есть облако (AWS в данном случае). У него есть регионы. У нас есть приложения. А еще есть окружения вроде dev и prod. Между этими сущностями (регион, объект, приложение) отношение N-N везде, да еще и с необязательной принадлежностью. Еще аккаунт можно приплести, он тоже перцу добавляет.
В этой ситуации, когда нам надо собрать из всего этого рабочий конфиг, так и стоит действовать. Распиливаем все по сущностям, делаем наборы конфигов для аккаунта, окружения и там все такое, после чего это программно комбинируется аналогом SELECT * FROM a INNER JOIN b ON xxx INNER JOIN c ON yyy;
Да, сложно. Да, неинтуитивно. Но зато если ты давеча переименовал какую-то мелкую хрень, она у тебя переименовалась везде, где надо.

Но это, как выяснилось, не наш метод. Делаем иерархическую структуру папочек: регион-приложение-окружение. Ну ладно, общие настройки на регион наследуются, потому что терраформ умеет find_in_parents(). Ну а дальше у тебя столько полноценных конфигов приложения, в скольких регионах оно запилено. И еще хлеще с окружениями. Да, я понимаю, что те же коннстринги и все такое будут уникальны для каждого приложения... хотя темплейтинг вроде postgresql://{{app_user}}:{{app_password}}@{{env_psql}}:{{env_port}}/{{app_db}} это решает чаще, чем казалось бы.
Но нет. В итоге колоссальный объем самоповторений, репликация пусть коротенького, но одного и того же скрипта в 100500 экземплярах (что сразу делает его навечно неизменяемым, пусть он и написан через Ж).
Короче, я не могу понять, как до этой архитектуры доходили люди с сертификатами, катающиеся на re:Invent и занимающиеся Амазоном сильно дольше меня.

Возможно, они просто ни разу не работали с СУБД.