Sly32

Ответ простой, скука. Все пытаюсь выжать из него хоть что-то дельное.

Это как раз не самое страшное. Хуже что и ума для того чтобы его сделать у него тоже не сильно много.

На чудик, можешь посмотреть, как это работает в личку линку отправил.
Если кому интересно пишите, покажу

Конечно не знаешь. Если бы знал - давно бы уже привел бы пример, как бы ты хранил данные, как получал и как обрабатывал. Могу поспорить, что на собесе после 3-5 вопросов по бд я бы уже прекратил интервью и отправил бы тебя домой. Спросил бы тебя про атомарность, уровни изоляции, типы баз и отличия, про, например, реплицирование. До вопросов  - как строятся индексы, как читаются, когда нужны а когда нет, функции, эксплэйны  бы точно не дошли. 
Раз уж для тебя сложность написать простецкий пример.

И ходить в базу чтобы получить 25-30 фиксированных значений - это как раз подход вебмястера, который не понимает, как это работает и будет микроскопом гвозди заколачивать. 

Фантастика, ты даже не знаешь что такое база данных))) А как по твоему, данные эти извлекаются? Волшебство? Нет, это СУБД, в которой свой язык, которая строит реляционные модели, которая строит индексы. Сколько  операций происходит даже при простом селекте? Открыть коннект, отправить запрос, обработаеть его, вытянуть данные из таблиц, вернуть, закрыть соединение. И это мы еще даже не начали работать с фронтом. Потому что дальше - обработай полученные данные, отправь это на фронт. Если бы ты умел, ты бы давно сам написал профайлер и увидел, сколько памяти и времени займет работа с базой  и сколько - обратиться к файлу. 

А давайте, голубчик, вы приведете примерчик запросика, который будет из таблички выгребать все данные по ключу. Потом профилируем запрос и сравним скорость запроса в базу данных и скорость вычитывания данных  из json-файла. Причем я его загружаю на бэке, вычитываю из него только нужный мне ключ и на фронт отправляются уже сформированный словарь, который напрямую используется в шаблонизаторе и который весит мизер. Надеюсь вы в состоянии прочитать 10 строчек кода, которые я привел. Также, раз вас заинтересовала эта тема, надеюсь в с начала читали и заметили, что вариант с вычиткой файла - на первом этапе, в дальнейшем это переедет в noSQL базу данных, по сравнению с которой ни одна реляционнка и близко не сравниться . Вообще есть вариант уйти в графовую базу.

Жду от вас ответ - как вы будете хранить данные в базе(таблица) и какие будете строить запросы для получения данных. В идеале - как будете все это применять на фронте.

Надеюсь, вы не уподобитесь известному персонажу тут.

У меня примерно похожее решение. Только роутинг в fastapi не требует создавать папки. 

В любом случае Хранить нужно в json - это самое удобное и масштабируемое решение

Да, можно так хранить. Но я сразу  вижу несколько сложностей, одну из которых ты уже привел - разные запросы под разные меню. Мне нужно универсальное решение с минимумом запросов, тут цикломатическая сложность на выходе должна быть О(1) иначе решение неправильное.

Дальше. Простой запрос по языку типа SELECT * FROM table WHERE table.lang='ru',  мне выдаст n-ое количество строк, как мне потом обрабатывать это? Jinja2 шаблонизатор  использует очень простой конструктор работы с контекстом в виде словарей и мне не очень хотелось бы городить огород с сериализацией.
то есть  если мне в респонсе пришел такой словарь {"ru": {"mentee": "ученик"}}, то я просто в шаблоне использую:

<ul class="navbar-nav me-auto mb-2 mb-lg-0">
   <li class="nav-item">
        <a class="nav-link href="/mentee/{{user_id}}">{{lang.mentee}}</a>
   </li>

И все. Если это обьект респонса из базы - мне нужно будет в цикле найти все нужные значение. Такие вещи не стоит отдавать на фронт, с бэка уже должен приходить ответ в нужном формате.

Это точно - урок что ты ничего не знаешь, умеешь только дуть щеки и попытка с тобой нормально общаться - бесполезна. Ты почему то решил, что мне нужна твоя помощь 😂. А мне хотелось просто подискутировать на технические темы. И только ты тут пытаешься развести срач, остальные по делу отвечают. Напрашивается очевидный ответ.

Как обычно, надежда на нормальный диалог с тобой - бессмысленна. Тебе не лень писать про свои обидки, но ты не в состоянии привести 2 строки кода - как ты думаешь, это не говорит о твоем уровне?Может у тебя когнитивный диссонанс? потому что сначала это

но потом

Наверное, только вот я не использую Джанго тут.
Внем асинхронка так себе, ОРМ медленный, нет надобности в нем в контексте моей задачи.

Пока что ты демонстрируешь не то что утрату, а полное отсутствие.

Но!!!! Я еще раз предлагаю отставить детские обидки и поговорить на технические темы. Это полезно будет и тебе и мне. Продемонстрируй навыки нормального разработчика, а не обидчивого школьника. Думаю это будет полезно всем. Мне реально было бы интересно, как кто-то, ты в том числе видит реализацию этого.
Я пока пытался сформулировать, пришел к выводу, что мне реально проще хранить языковые настройки в json файле и один раз оттуда забирать нужный язык. Примерно так

[json]
{
    "en":{
        "home": "home",
        "subjects": "subjects",
        "mentors": "mentors",
        "scheduler": "scheduler",
        "news": "news",
        "adverts": "adverts",
        "search": "search"
    },
    "ru": {
        "home": "домой",
        "subjects": "предметы",
        "mentors": "преподаватели",
        "scheduler": "расписание",
        "news": "новости",
        "adverts": "обьявления",
        "search": "поиск"
    }
}
и обработчик в 10 строк
[lang.py]
import os
import json
from fastapi import Depends, Path

def get_language_dependency(lang: str = Path(...)) -> dict:
    return get_language(lang)

def get_language(lang: str = "en") -> dict:
    file_name = "lang_settings.json"
    file_path = "".join((os.getcwd(), "/src/settings/", file_name))
    with open(file_path, "r") as f:
        data = json.load(f)
        lang = {"lang": data.get(lang)}
        if not lang:
            return {"lang": data.get("en")}
        return lang

При этом при переходе на БД и переделывать ничего не надо. Монго и так работает с джейсонами, в постгрес тоже есть поле типа json и никакой огород не надо городить

Побьешь мое решение  своим?

Докажи хоть раз что ты не пустозвон. Приведи пример. Пока я вижу так. Чтоб было проще, базовый текст, на английском - так будет проще строить роутинг. Есть вкладки для en: ['mentor', 'mentee', 'schedule', 'subject', 'news']. Пока что все прекрасно кладется в одну таблицу:

Все вроде как прекрасно. Но тут я решил добавить радел, например, реклама. Добавлять новый столбик?
А если раздел предметы содержит подразделы - Математика, История, Химия.... Куда их пихать?
Жду твои варианты.
И давай без надувания губ. Чисто техникал дискуссия. Может, я что-то упускаю, усложняю, а ты видишь простой путь.

То есть ты не знаешь как? Мне вот почему то кажется что хранить все данные в одной таблице не получится