- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Именно так у меня реализовано на многих сайтах
Не понимаю, зачем городить огород с кучей шаблонов, когда достаточно одного.
Вот еще счас смотрю в графовую базу данных типа AWS Neptune. Она сверхбыстрая и не только под шаблоны подойтет. Кто-нибудь пробовал?
Arbnet, ты же там хотел соцсеть свою создать, значит должен был с такой знаком - как оно - стоит выделки?
Ты бы прочитал сначала внимательно. Это не вариант3 а вариант 2 у меня. И я уже выразил консерн свой - это лишний запрос в базу данных.
Скорее это вариант 1. При этом будет оперативка загружаться и если будет много запросов одновременно, то сервак будет не справляться. Даже если на странице только одну фразу надо перевести в операционную всё равно целый файл всех слов будет грузится и для каждого запроса..
А вариант 2 ещё хуже первого.. так как все переводы в одном файле если я правильно понял.
ЗЫ. Так что вариант 3 самый лучший.
Именно так у меня реализовано на многих сайтах
Да, этот подход имеет право на жизнь, но если это не сильно нагруженный сайт, иначе будут проблемы из-за нехватки оперативки.
Но это самый простой и эффективный способ если шаблоны нативные.
ты же там хотел соцсеть свою создать, значит должен был с такой знаком - как оно - стоит выделки?
Я всегда везде делал по 3 варианту
Скорее это вариант 1. При этом будет оперативка загружаться и если будет много запросов одновременно, то сервак будет не справляться. Даже если на странице только одну фразу надо перевести в операционную всё равно целый файл всех слов будет грузится и для каждого запроса..
А вариант 2 ещё хуже первого.. так как все переводы в одном файле если я правильно понял.
ЗЫ. Так что вариант 3 самый лучший.
Я тебя вообще не понимаю, ты пишешь:
Вариант 3 как нормальные прогеры делают
Не вдаваясь в терминологию твою - так работает любой шаблонизатор. Я же привел вариант хранения данных выше. Это результат ответа из базы данных. Которые шаблонизатор, как ты говоришь по меткам, хотя это контекстные переменные матчит по шаблону страницы. Сколько в твоем варианте нужно запросов в реляционную базу? В каких таблицах это будет храниться? И сколько запросов будет в моем варианте?
Я всегда везде делал по 3 варианту
Что ты делал-то? Есть примеры? И в данном случае я спрашивал про опыт графовой БД а не как собрать шаблон.
Сколько в твоем варианте нужно запросов в реляционную базу? В каких таблицах это будет храниться?
1 запрос, 1 таблица
ЗЫ. Делай как знаешь, если не знаешь как по нормальному делается.
Даже если на странице только одну фразу надо перевести в операционную всё равно целый файл всех слов будет грузится и для каждого запроса..
Только в том случае, если сделано это не правильно. Так ни кто не делает.
Вот еще счас смотрю в графовую базу данных типа AWS Neptune. Она сверхбыстрая и не только под шаблоны подойтет. Кто-нибудь пробовал?
Я не пробовал. Но. А стоит ли оно того. Это необходимо если каждая страница каждый раз генерируется на каждом хите. В остальном кеширование (страницы полностью или блоками) или SSG. Т.е. получится ли в итоге значимый профит от скорости БД.
Только в том случае, если сделано это не правильно. Так ни кто не делает.
Ну да под каждый плагин, каждый раздел свои языковые файлы, так точно только дауны и могут делать..
В остальном кеширование
Не хило же придётся за дисковое пространство за хост платить, в файлах+бд, да ещё и в кэше.. кучеряво живёте 😁