kn0ckn0ck

Это всегда компромисс: нормализация vs удобство/производительность. Денормализация часто применяется на практике, поэтому плохим решением я это не считаю, при условии, что в БД после этого не будет разводиться бардака. Как уже этого достигать - другой вопрос.

Если много джоинов не вредят производительности (например, в таблицах мало данных), то проще обойтись вьюхами, чтобы сократить время на разработку (использование этих таблиц в запросах) и не допустить нарушения целостности при обновлении/вставке/удалении.

В разных СУБД есть нативные механизмы поддержки денормализованных отношений, например, что-то типа материализованных представлений в Oracle.

А вообще, нормализация - враг производительности.

Airtable

С любыми базами данных можно не использовать кеширование и работа будет ускоренная до чертиков.

Подобные задачи в DevOps решаются известными инструментами Ansible, Puppets, Chef - выбирай на вкус и цвет.

Здесь вам нужен суррогатный первичный ключ в таблице Технологическая карта. Я не уверен, что это решение проблемы, возможно, здесь вообще реляционная модель некорректная.

За пол дня собрал такой сервис: https://github.com/cutecare/gas-map, под капотом:
1. elasticsearch принимает данные (json post) и отдает их в карту, либо на аналитику (kibana)
2. на Яндекс.Карте отмечаются кружками данные, которые берутся из elasticsearch

Работает очень быстро, 700 тыщ в сутки - это десткий лепет для Elasticsearch. Есть масса альтернатив конечно.

База данных состоит их схемы и данных. Данные могут быть разные: управляющие, пользовательские и т.п. За схему и управляющие данные (справочники, например) отвечает миграция. С этим как я понял у вас Ok.

Зависимость кода от данных - это очевидный антипаттерн дизайна, который необходимо устранить. Тем более, если код зависит от пользовательских данных, типа ID пользователя.

С другой стороны, разработчики предпочитают работать с данными, приближенными к боевым. Однако, здесь могут быть риски, например, отправка тестового письма реальному пользователю. Процесс выглядит обычно так:

1. сливаем дамп с боевой базы данных;
2. загружаем его на тестовый сервер;
3. запускаем процедуру обфускации (удаления чувствительных пользовательских данных);
4. загружаем управляющие данные, соответствующие тестовому окружению (если это нужно).

Необязательно логика запроса влияет на его производительность. В большей степени на это может влиять специфика данных, физика размещения данных и т.п.

Если уверены, что проблема именно в этом запросе, то анализировать нужно не запрос, а план его выполнения (explain ...). Без плана ничего дельного сказать нельзя. Можно только предложить абстрактные идеи для оптимизации:

1. продуманные индексы
2. денормализация
3. материализованные представления
4. партиционирование
5. типы движков

Да, такой инструмент называется темпоральные СУБД. Кстати, многие современные РСУБД имеют необходимые для этого расширения или механизмы.

Если словосочетание "правила обеспечения ссылочной целостности" не вызывает отторжения, то это они :)
D:R - delete restricted
U:R - update restricted
ну и т.д.

Выбор базы данных - это архитектурное решение, которое повлияет на все в вашем проекте. Относиться к выбору нужно ответственно, а не поверхностно - как сейчас.

Все данные всегда как-то связаны, поэтому это не может быть критерием для выбора технологии их хранения/извлечения.

Если вы на проекте принимаете архитектурные решения, то рассмотрите множество потенциально возможных сценариев использования данных, видов данных и т.п. Прям вот садитесь и выписывайте: а) нужно это, б) нужно то, в) а потом еще так, г) ...

Составив таблицу вариантов использования (требований по сути) проработайте сильные и слабые стороны для каждой из технологий, которая вам кажется здесь применимой.

Сформируйте системное и взвешенное решение.

Раньше ругали за то, что языки/библиотеки расточительно относятся к памяти - не экономят ее. Сейчас ругают за то, что расточительно относятся к сервисам/технологиям - шлеп sql, шлеп nosql и готово.

Описанная задача не является архитектурно значимой, это к вопросу дизайна вашего кода. Почему бы не хранить дату/время в линейном формате, например, аналогично UNIX_TIMESTAMP? На этом пространстве легко решаются описанные задачи даже на обычном калькуляторе, не говоря об elasticsearch...