- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Контент тоже может только изредка меняться. Так что пожалуйста: поналепил кучу файлов с контентом - и в путь, никто не мешает. Просто это принципиально разные подходы, и без разницы, контент это или ваши "интерфейсы".
Но контент обычно периодически добавляется.
Все равно, мое мнение, если есть возможно и это рационально, то нужно по возможности меньше делать запросов к базе данных. Мне было удобнее сделать мультиязычность интерфейса на хранении этого текста в файлах (пхп массивы).
На сервере всё хранится в файлах на диске или в оперативной памяти. В том числе и БД. Но БД специально оптимизирована именно для работы с данными. Поэтому где "быстрее" - большой вопрос. Зависит от структуры данных и их объёма.
Почему это вопрос? Лично я взял и проверил - это называется профилирование запросов. И как раз на маленьких обьемах БД проигрывает всухую. Я уже писал. файлы, в которых хранятся данные сами себя читать не умеют. Для этого над БД висит СУБД. И это не самая легкая штука. Тут не надо оперировать догадками, это проверяется за 5 минут.
В файлах json можно вообще хранить все данные
Нельзя. Точнее конечно впихнуть-то можно, но вот эффект какой будет? json - для хорошо структурированных данных. SQLDB - гибче, проще работать с разными форматами и типами.
Для реализации мультиязычности правильнее использовать те же базы данных.
Я не вижу обоснований, можно тут поподробнее? Почему правильнее? Каждый раз ходить на сервер, чтобы собрать менюшку из 20-30 значений? Думать как реализовать вложеность?
Ну и опять же, для тех кто внимательно читал - хранение в файле - это прототип, чтобы потом перейти к noSQL базе, а она все равно будет мне нужна. Сответственно я не вижу причин мучать сервер лишним запросом, когда есть решение удобнее.
хранение в пхп файлах, сам так храню,
Вот интересно, что? Это очень дилетанские подход. Хранить прямо в коде можно данные, которые гарантированно никогда не изменятся после выхода в прод. И даже в этом случае это лучше хранить в переменных окружения, вычитывая их из .env файла.
и расходы на чтение файла и на работу интерпретатора одинаковые
нужно по возможности меньше делать запросов к базе данных
Однозначно. Просто тут вебмастера, воспитанные на жутком вордпрессе, котором все собирается из базы. А вместо оптимизации начинается игра с кэшами...
Почему правильнее?
Потому что если ты избрал способ хранения данных в реляционной БД, то правильнее придерживаться этого выбора, если нет достаточных оснований для иного. Единообразие всегда предпочтительнее при прочих равных условиях.
Каждый раз ходить на сервер, чтобы собрать менюшку из 20-30 значений?
Вообще-то во всех популярных CMS почему-то "ходят" и собирают. Но никто не мешает тебе вообще жёстко вписать меню в шаблон, так тоже делают.
Думать как реализовать вложеность?
Всё уже давно придумано.
И что это у тебя за проект такой, в котором мультиязычность реализована только для меню? А всё остальное - на одном языке будет?
для тех кто внимательно читал
Внимательно читать ваши перепалки - это работа не для ленивых.
это прототип, чтобы потом перейти к noSQL базе
Тоже странная нелюбовь к SQL базам. И нафига прототипы, сразу нельзя запрограммировать как положено? Нафига огороды городить?
Короче, это какая-то специфика твоего проекта. На сайтах так не делается.
Вообще-то во всех популярных CMS почему-то "ходят" и собирают.
Это их право. Я не пишу сайты, я занимаюсь сервисами. Тут немножко другие амбиции. Упираться в одну базу не вижу причин.
Это их право. Я не пишу сайты, я занимаюсь сервисами. Тут немножко другие амбиции. Упираться в одну базу не вижу причин.
Значит, людей вводит в заблуждение заголовок темы.
Вот интересно, что? Это очень дилетанские подход. Хранить прямо в коде можно данные, которые гарантированно никогда не изменятся после выхода в прод. И даже в этом случае это лучше хранить в переменных окружения, вычитывая их из .env файла.
и расходы на чтение файла и на работу интерпретатора одинаковые
языковые файлы, если вы не в курсе, они есть во многих популярных cms (например DLE) и хранятся также, как и у меня в отдельных пхп файлах с объявлениями массивов, в отдельных директориях для каждого языка, они как раз и не изменяются, в вашем интерпретаторе расходы может быть и одинаковые, а в пхп нет, при включённом opcache они компилируются в байт код и никакого парсинга кода программы в дальнейшем не происходит, всё работает очень быстро, более того, даже скомпилированные пхп файлы я храню на рам диске, всё читается из оперативной памяти
PS: и да, если хотите не по дилетантски, используйте gettext https://habr.com/ru/articles/73554/ , а я буду наслаждаться высокой скоростью своего велосипеда
Забавно. сначала ты агитируешь за
нужно ввести в указанной таблице поле с идентификатором меню и вытаскивать записи по нему и по языку
а потом оказывается, что
WebStorm #:
языковые файлы, если вы не в курсе, они есть во многих популярных cms (например DLE) и хранятся также, как и у меня в отдельных пхп файлах
они как раз и не изменяются, в вашем интерпретаторе расходы может быть и одинаковые, а в пхп нет,
По сравнению с чем? Сделать запрос в базу, хранить в коде, хранить в файлах? Вы уж определитесь. В Питоне тоже весь код компилится в байт-код. Хранить настройки в коде - bad practice, почитайте может книги по чистому коду. Причин изменения кода может быть две - обнаружение бага и изменение функциональности. Если мне для расширения меню нужно менять данные в коде - это не код а мусор.
Gettext - тарая и известная штука, полезная, но в моем случае избыточная. С таким же успехом я могу AI использовать для перевода.
Моя цель - с наименьшими расходами перевести интерфейс.
Значит, людей вводит в заблуждение заголовок темы.
Ну вот и стоило бы прочитать сначала, о чем речь, прежде чем приходить и демонстрировать отсутствие понимания вопроса. Для моих проектов нормально использование нескольких ресурсов для хранения данных - Mongo/Dynamo, Postgresql/Oracle, Redis, теперь вот на горизонте Neptune графовый.
Мне неинтересно нарисовать сайтик под Adwords, мне интересен сервис, который будет полезен. И повторюсь, по свои задачи - свой способ. Для авторизации и хранения данных пользователя лучше sqlDB ничего не придумано. А например создать курс какой то по предмету с квизами, задачами - тут уже noSql. И так далее.