Ну вот и стоило бы прочитать сначала, о чем речь, прежде чем приходить и демонстрировать отсутствие понимания вопроса. Для моих проектов нормально использование нескольких ресурсов для хранения данных - Mongo/Dynamo, Postgresql/Oracle, Redis, теперь вот на горизонте Neptune графовый.Мне неинтересно нарисовать сайтик под Adwords, мне интересен сервис, который будет полезен. И повторюсь, по свои задачи - свой способ. Для авторизации и хранения данных пользователя лучше sqlDB ничего не придумано. А например создать курс какой то по предмету с квизами, задачами - тут уже noSql. И так далее.
Забавно. сначала ты агитируешь за
нужно ввести в указанной таблице поле с идентификатором меню и вытаскивать записи по нему и по языку
а потом оказывается, что
WebStorm #:языковые файлы, если вы не в курсе, они есть во многих популярных cms (например DLE) и хранятся также, как и у меня в отдельных пхп файлах
По сравнению с чем? Сделать запрос в базу, хранить в коде, хранить в файлах? Вы уж определитесь. В Питоне тоже весь код компилится в байт-код. Хранить настройки в коде - bad practice, почитайте может книги по чистому коду. Причин изменения кода может быть две - обнаружение бага и изменение функциональности. Если мне для расширения меню нужно менять данные в коде - это не код а мусор.
Gettext - тарая и известная штука, полезная, но в моем случае избыточная. С таким же успехом я могу AI использовать для перевода. Моя цель - с наименьшими расходами перевести интерфейс.
Это их право. Я не пишу сайты, я занимаюсь сервисами. Тут немножко другие амбиции. Упираться в одну базу не вижу причин.
Вот интересно, что? Это очень дилетанские подход. Хранить прямо в коде можно данные, которые гарантированно никогда не изменятся после выхода в прод. И даже в этом случае это лучше хранить в переменных окружения, вычитывая их из .env файла.
и расходы на чтение файла и на работу интерпретатора одинаковые
Однозначно. Просто тут вебмастера, воспитанные на жутком вордпрессе, котором все собирается из базы. А вместо оптимизации начинается игра с кэшами...
Почему это вопрос? Лично я взял и проверил - это называется профилирование запросов. И как раз на маленьких обьемах БД проигрывает всухую. Я уже писал. файлы, в которых хранятся данные сами себя читать не умеют. Для этого над БД висит СУБД. И это не самая легкая штука. Тут не надо оперировать догадками, это проверяется за 5 минут.
Нельзя. Точнее конечно впихнуть-то можно, но вот эффект какой будет? json - для хорошо структурированных данных. SQLDB - гибче, проще работать с разными форматами и типами.
Я не вижу обоснований, можно тут поподробнее? Почему правильнее? Каждый раз ходить на сервер, чтобы собрать менюшку из 20-30 значений? Думать как реализовать вложеность?
Ну и опять же, для тех кто внимательно читал - хранение в файле - это прототип, чтобы потом перейти к noSQL базе, а она все равно будет мне нужна. Сответственно я не вижу причин мучать сервер лишним запросом, когда есть решение удобнее.
{ "en": { "subjects": { "subjects": { "chemistry": "chemistry", "math": "mathematics" } }, "mentors": "mentors", "scheduler": "scheduler", "news": "news", "adverts": "adverts" }, "ru": { "subjects": { "предметы": { "chemistry": "химия", "math": "математика" } }, "mentors": "преподаватели", "scheduler": "расписание", "news": "новости", "adverts": "обьявления" }}
И отдельный метод соберет не просто перевод, а из ключей второго уровня создаст меню сразу с переводом. Также добавил уровнеь вложености. Пока только один, но ничего не мешает сделать их сколько угодно. Если из этого вырастет коммерческий проект - редактирование меню будет проходить в админке, не нужно будет руками править что-то в json-е, при этом будет сразу валидироватся правильность добавления данных. И скорее всего подключу тут уже AI - отдаешь ему структуру меню и язык и он сам собирает переводы.
PS. Отстаньте уже от Arbneta, он в очередной раз показал что ничего из себя не представляет, не вижу смысла загаживать техническую тему
Ответ простой, скука. Все пытаюсь выжать из него хоть что-то дельное.
Это как раз не самое страшное. Хуже что и ума для того чтобы его сделать у него тоже не сильно много.
На чудик, можешь посмотреть, как это работает в личку линку отправил.Если кому интересно пишите, покажу
Конечно не знаешь. Если бы знал - давно бы уже привел бы пример, как бы ты хранил данные, как получал и как обрабатывал. Могу поспорить, что на собесе после 3-5 вопросов по бд я бы уже прекратил интервью и отправил бы тебя домой. Спросил бы тебя про атомарность, уровни изоляции, типы баз и отличия, про, например, реплицирование. До вопросов - как строятся индексы, как читаются, когда нужны а когда нет, функции, эксплэйны бы точно не дошли. Раз уж для тебя сложность написать простецкий пример.
И ходить в базу чтобы получить 25-30 фиксированных значений - это как раз подход вебмястера, который не понимает, как это работает и будет микроскопом гвозди заколачивать.
Фантастика, ты даже не знаешь что такое база данных))) А как по твоему, данные эти извлекаются? Волшебство? Нет, это СУБД, в которой свой язык, которая строит реляционные модели, которая строит индексы. Сколько операций происходит даже при простом селекте? Открыть коннект, отправить запрос, обработаеть его, вытянуть данные из таблиц, вернуть, закрыть соединение. И это мы еще даже не начали работать с фронтом. Потому что дальше - обработай полученные данные, отправь это на фронт. Если бы ты умел, ты бы давно сам написал профайлер и увидел, сколько памяти и времени займет работа с базой и сколько - обратиться к файлу.
