надо выстраивать правильную структуру. у программистов должен быть ведущий, он пусть их и проверяет

Если ты делаешь селект из кучи таблиц, то хотя бы в результате сразу понятно что за departament_name и откуда оно растёт без переименований столбцов в результате. Про join уже написали. Названия не должны быть  излишне пространны, но должны максимально описывать то, что в поле лежит.
Только хлебушки называют в коде переменные литерами "a", "b", "c" и так далее, без привязки названия к содержимому. Только такие же хлебушки лепят в базу триста полей "name" по разным таблицам.

ну строго говоря, индексов в SQL нет ;)

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

Хотел поумничать? 😛
Так-то в SQL и таблиц нет и сиквенсов и вьюх и db-линков и т.д.
Это просто plain-text

Например, это тривиально решается tuning пары параметров. ;)
И, кстати, взять данные из RAM (shared buffers) по-прежнему гораздо быстрее, чем считать их с SSD.
Т.е. этот фундамент совершенно правильный.

В стандарте SQL индексов в самом деле нет... но кого это волнует, по большому счёту? ;)

я такой хлебушек, что плохого писать разные префиксы к name которые могут пересекаться? использовать алиас таблицы
и все понятно.
особенно когда структура например древовидная и ваш *_name уже также должен быть изменен как parent_*_name.

Но современные nmve же весьма приближаются по идее. Да, с io в ядре ещё есть над чем работать, но аппаратно они прямо совсем почти догоняют. И шины pci-e нынче адищевой толщины.
Так что утверждение вроде бы и всё ещё верное, но, в то же время, разрыв памяти и дисков уже далеко не такой мрачный и хтонический как раньше.

А от программиста баз данных наивно ожидать знания python и веб-сервисов вообще.
Т.е. специализаций, на самом деле, много.
А нанимать кого попало (лишь бы подешевле!) — идиотская "экономия на спичках", IMNSHO. ;)

Вот это — неправильная структура. Но это offtopic, да.

Если мы говорим о запросе с момента его попадания на сервер БД, то не говорить об индексах и прочих объектах уже нельзя. Ибо на основе всего этого строится план запроса. А без плана запроса SQL-запрос - это просто текст. Ничего более..

Зависит от задачи и данных, вот честно. Может и партиционирование, только делайте так, как в текущей версии нужно делать штатными средствами, я вас умоляю)
Что хранить то нужно суточно? Метрики?

И в некоторых [специализированных] реализациях SQL-СУБД индексов (по крайней мере, создаваемых пользователем) тоже вообще нет, кстати.

унес цитату.

memcached лично мне больше нравится.

я вам ее не навязываю :) вы может дба ставить проверять за программистами.

Если Вам важно качество продукта, не стоит её навязывать кому-либо вообще, я вот о чём. ;)

А расскажи, где ты его применяешь на практике? Я сейчас на степике курс прохожу обзорный про NoSQL. Как раз раздел про memcached закончил. Но пока не оч в курсе, где бы его можно было применить на практике.

Сейчас - нигде. Кеш для веб-приложений.