И вот я возвращаюсь к идеи полностью переместить ее в оперативку. Просто как правильно и сколько можно вырезать из условных 64 гб, когда база весит 10 гб + запас который нужен для работы самого мускул, кеш и прочее. Отсюда думать, как быстро написать скрипты, которые будут быстро копировать нужные конфиги, пути, файлы, чтобы быстро развернуть после возможного отключения сервера, что опять по аптайму показывает возможно и не понадобится.
А Redis не подходит для этого?
Просто такая реализация - это когда сам занимаешься проектом. А так должна быть защита от дурака.
Это же меню нужно связать со страницами. Для страницы обычно должны определяться подключаемые модули. Есть вероятность рассинхронизации страниц и меню.
По любому нужно связывать меню со страницами даже если это на файлах организовано (или писать админку или руками править файл). В меню должен быть или ID страницы (но это снова обращение в базу чтобы узнать урл страницы) или прописывать сразу полный урл (но в таком случае при его смене в базе можно получить 404).
Поэтому там разные варианты могут быть в зависимости от проекта и кто его будет вести.
Как вариант все в 1 таблице (меню и страницы), при ее изменении делать экспорт в файл (тот же джосн) и быть уверенным, что работаешь с актуальными данными. и т.д.
Но контент обычно периодически добавляется.
Все равно, мое мнение, если есть возможно и это рационально, то нужно по возможности меньше делать запросов к базе данных. Мне было удобнее сделать мультиязычность интерфейса на хранении этого текста в файлах (пхп массивы).
На сервере всё хранится в файлах на диске или в оперативной памяти. В том числе и БД. Но БД специально оптимизирована именно для работы с данными. Поэтому где "быстрее" - большой вопрос. Зависит от структуры данных и их объёма.
Вы хотите сказать что обращение к базе данных будет быстрее, чем считать файл? (не учитывая использования опкэш и мемкэш)
Здесь же речь шла о словах из интерфейса, а не контента. Контент в базе хранится. А зачем мне для текста из интерфейса (при мультиязычности) хранить его в базе данных, если это изредка только меняется? Подключил файл с нужным языком и сразу используй (json или просто обычный массив в php файле).
Вот именно, зачем их в базе хранить, если они не часто изменяются. Практики там наверное вообще 0 ))
Тогда зачем придумали БД по вашему? Хранили бы всё в файлах, зачем БД нужно тогда? 😆
А зачем все пихать в БД? Это одно из наиболее узких мест для производительности. И сколько таких запросов в бд в том же wp чтобы отобразить одну страницу. А еще же нужно плагинами обвешаться как новогодняя елка. Вот здесь точно для лендинга будет впс мало (без кэширования)
Обращение к файлам же намного быстрее, чем к БД. Просто не нужно пихать все в один файл. В зависимости от версии и места подключаем en_menu, en_shop (как тот же идентификатор в БД) и т.д. json_decode php преобразует в объект или массив. Берем переменную и подставляем.
Сначала нужно иметь исходные данные. Вы хотите написать универсальное решение? Это большой проект? Кто занимается добавление новых и переводом?
Я для себя так сделал мультиязычность (и там не 3 языка):
На файлах. Идет масив $L_ar_main [ название1 => текст1, название2 => текст2, ].
Для каждого языка есть своя директория, в ней отдельные файлы: основной (те слова что везде на сайте используются), а дальше например для раздела 1, раздел 2 и т.д. (чтобы лишние файли не подключать)
На пхп подставляются в шаблон (ну и кэш есть на отдельные страницы).
Сделал EN версию словаря, а потом написал код который взял слова с англ. списка и сформировал список с разделителем:
слово 1 @@ слово 2 @@ слово 3 @@и т.д.
Закинул этот список в переводчик, результат вставил в поле формы, где код снова это разобрал, соединил с названиями переменных, сформировал массив и записал в файл соответствующей языковой версии.
С базой данных конечно проще наверное работать, если админку делать для переводов.
Если бы делал таблицу (или наверное разделил на несколько таблиц), то по столбцам было бы:
уникальное название переменной / en / ru/ и т.д. где идет переведенный текст (при необходимости нового языка добавляем новый столбец)
Основные сервера Телеги находятся в Питере в одном здании с офисом ФСБ. Плюс Дуров 50 раз за год катался в Россию. Плюс замышлял свою платежную систему для обхода западных санкций, наложенных на Россию. Вот и делай выводы для чего задержали Дурова во Франции. Его самого и его детище ждут трудные времена в плотном кольце западных спецслужб 😁
Да если так посмотреть, то там и отжим ВК был хорошей легендой чтобы внедриться на запад и создать телеграм. + программированием занимался его брат (кажется кандидат математических наук, который был или есть сотрудником одного из институтов).
А так конечно, он все шифрует ))
И на что это повлияет в будущем? Во франции перестанут продавать наркотики? Или твоя жизнь хоть как-то изменится в лучшую сторону?
Да мне то все равно - я даже им не пользуюсь (лучше другими пользоваться). Это же по тв шухер навели что нужно чиновникам переписки удалять ) А еще его обзывают начальником связи и боятся что прикроют этот канал
