Забавно. сначала ты агитируешь за
нужно ввести в указанной таблице поле с идентификатором меню и вытаскивать записи по нему и по языку
а потом оказывается, что
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 фиксированных значений - это как раз подход вебмястера, который не понимает, как это работает и будет микроскопом гвозди заколачивать.
Фантастика, ты даже не знаешь что такое база данных))) А как по твоему, данные эти извлекаются? Волшебство? Нет, это СУБД, в которой свой язык, которая строит реляционные модели, которая строит индексы. Сколько операций происходит даже при простом селекте? Открыть коннект, отправить запрос, обработаеть его, вытянуть данные из таблиц, вернуть, закрыть соединение. И это мы еще даже не начали работать с фронтом. Потому что дальше - обработай полученные данные, отправь это на фронт. Если бы ты умел, ты бы давно сам написал профайлер и увидел, сколько памяти и времени займет работа с базой и сколько - обратиться к файлу.
А давайте, голубчик, вы приведете примерчик запросика, который будет из таблички выгребать все данные по ключу. Потом профилируем запрос и сравним скорость запроса в базу данных и скорость вычитывания данных из json-файла. Причем я его загружаю на бэке, вычитываю из него только нужный мне ключ и на фронт отправляются уже сформированный словарь, который напрямую используется в шаблонизаторе и который весит мизер. Надеюсь вы в состоянии прочитать 10 строчек кода, которые я привел. Также, раз вас заинтересовала эта тема, надеюсь в с начала читали и заметили, что вариант с вычиткой файла - на первом этапе, в дальнейшем это переедет в noSQL базу данных, по сравнению с которой ни одна реляционнка и близко не сравниться . Вообще есть вариант уйти в графовую базу.
Жду от вас ответ - как вы будете хранить данные в базе(таблица) и какие будете строить запросы для получения данных. В идеале - как будете все это применять на фронте.
Надеюсь, вы не уподобитесь известному персонажу тут.
