Александр Филиппенко

Я в своё время чтобы слезть с "сайтиков" брал на фрилансе задачи по темам в которых хотел разобраться. Демпинговал, срывал сроки, но разбирался, причём не на учебных примерах, а на реальных.
И со временем удалось попасть в продуктовую разработку, там развитие намного бодрее пошло.

Обычно прям написать реализацию или детально объяснить не просят, но общее понимание проверяют.
Например почему для индексов в БД используют именно B-tree, а не binary tree?
Или как отсортировать строки в файле который больше чем доступная оперативка?
В каких случаях отсортированность данных нам может помочь, и как? (поиск, слияние, пересечение)
Какие плюс и минусы у хэш-таблиц?

Выяснил наконец-то.
Оказывается, по какой-то причине эти режимы не совместимы с HDR режимом.
Отключение HDR в настройках MacOS помогает.

Поиск по любым колонкам решается инвертированными индексами.
Если хочется именно в рамках PostgreSQL остаться, можно перейти на jsonb поля с GIN индексом.
Также в elasticsearch такие запросы хорошо работают, но его готовить уметь нужно.

Можно создать уникальный индекс на все 3 поля, или триггер на вставку.

Создать где-то отдельно поле типа ARRAY с этими ID, и подставить в запрос
... where id = any(array_field)

1. Если в поле хранится число, то в качестве типа стоит использовать число. По ряду причин.
2.

select sum(prodcount::int) as cnt 
from production 
inner join admin_productions on production.prodname = admin_productions.adminproductname

3. Этот вопрос никак к сложным не относится.

Я делал одноразовые токены на Redis.
Создаётся ключ, командой SET или SETEX (в вашем случае можно склеить номер телефона и код), значение любое, например "1".
Команда DELETE <ключ> вернёт 0, если такого ключа не было, и 1 если он был, и сразу удалит его.
Язык тут особой роли не играет, но синглтон на РНР, не поможет в классическом случае, либо может привести к утечке памяти, в случае демонизации PHP.

Может сфера не ваша? А может фирма?
Я в далёком детстве решил что буду программистом, сейчас мне 29, и по прежнему мне вся эта сфера жутко интересна. Но я сменил несколько компаний разного размера и направленности, и не везде было комфортно работать. Были места где понедельника я ждал с предвкушением, а были где с ужасом. И стресс снимал дорогой едой)
Попробуйте поискать более интересную работу в качестве программиста. Ну или вообще сферу деятельности.
Кстати, проблемы с ЖКТ часто бывают чисто на нервной почве, мои закончились вместе с окончанием школы.

Во-первых стоит определиться с тем в каком именно направлении развиваться.
Во-вторых начать активно двигаться в этом направлении.
Книги, статьи, платные курсы, бесплатные курсы, видосы с докладами - всё будет полезным.
Мне вот тоже 29, и я на днях сменил сферу (если сменить программирование на программирование считается).
Кстати, глубоко понять некоторые вещи помогает опыт подготовки к докладам. Я сам как-то вызвался рассказать на местном митапе о базах данных, потому что считал что отлично их знаю. В итоге пока готовил презентацию, узнал ещё больше.
Потом все эти вещи пригождаются на собеседованиях.

Фреймворк тут вообще не при чём. Это вопрос правильной организации структуры БД, настроек, и индексов.
1 миллион - это не много. Я бы всё же взял PostgreSQL, и меняющиеся характеристики хранил бы, в jsonb поле c GIN индексом на нём.
Остальное зависит от конкретных задач, но у меня на одном проекте, поиск по 600к таких индексированных JSON'ов занимал ~10мс.
Так что и с миллионом проблем не будет. А вот при кривой структуре, и запросах... Я видел магазин который при 70к товаров пагинацию генерил 4 минуты. На шаред хостинге правда, на простеньком сервере было уже 8 секунд, что впрочем тоже ни в какие ворота.

1. Правильно думаете, только если Вы ищите такие пары среди ВСЕХ пользователей и ВСЕХ фильмов, то тут не обойдётся без полного сканирования всех 3 таблиц. Поможет кеширование, либо функциональные индексы, либо какие-то сводные таблицы управляемые триггерами или materialized view.
2. Active это bool или статус из списка? В любом случае тут нужен индекс по city_id и либо по полю active, либо частичный индекс where active = true. (надеюсь у Вас PostgreSQL)
3. Просто where с 2 условиями? Или есть подвох?

Запросы сложными тут быть не должны, но нужно предусмотреть правильные индексы чтобы это работало быстро.
Если нужна помощь именно с запросами, создайте https://www.db-fiddle.com/ с примерами данных, хотя бы строк по 10, чтобы ясна было структура

Не очень понял что нужно. Если передать данные из одного API в другое, то есть специальные сервисы универсальной интеграции.
Если нужно создать свой API, для работы со своими данными, то смотрите в сторону headless CMS, или hasura.io

У unit есть API. Можно менять настройки, добавлять/удалять инстансы приложения. Других применений я не вижу.