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