- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Невозможность расширения, выше уже писал.
Выше у тебя таблица какая-то кривая, поэтому и проблемы с расширением.
необходимоссть джойнить таблицы - сложный запрос для простой задачи - неоправданный расход ресурсов и время.
Я и написал: выбор варианта - в зависимости от конкретики проекта. Например, одно дело 2 языка, другое дело - 20 языков. И т.п.
Выше у тебя таблица какая-то кривая, поэтому и проблемы с расширением.
Я и написал: выбор варианта - в зависимости от конкретики проекта. Например, одно дело 2 языка, другое дело - 20 языков. И т.п.
Это пример таблицы, где имя колонки- ключ а строка- перевод. Плюсы- запрос отдает всего одну строку данных, по факту индекс не нужен для таблицы. Вариант- одна таблица где три колонки, язык, ключ значение. Легко добавлять новые поля, но будет селектится несколько строк, которые нужно преобразовать в формать удобный для шаблонизатора. Лишний код. Ну и плюс расширение до нескольких уровней вложенности усложняет задачу сразу
Ну и третий вариант, несколько таблиц, мне совсем не нравится
Это пример таблицы, где имя колонки- ключ а строка- перевод.
Это делается не так. Нужно делать таблицу, где каждая строка соответствует конкретному пункту меню.
Это делается не так. Нужно делать таблицу, где каждая строка соответствует конкретному пункту меню.
Вариант 2. А как хранить меню второго уровня?
Вариант 2. А как хранить меню второго уровня?
Указывать родительский пункт.
Указывать родительский пункт.
Но потом еще обрабатывать ответ. С утра набросал сравнительный профайлер по времени и простенький код
И вот результат без кэширования работы с базой:
Файл:
Execution time for get_language: 0.0002 seconds
{'subjects': {'subjects': {'chemistry': 'chemistry', 'math': 'mathematics'}}, 'mentors': 'mentors', 'scheduler': 'scheduler', 'news': 'news', 'adverts': 'adverts'}
База:
Execution time for get_language_db: 0.1151 seconds
[('en ', 'mentee ', 'mentee '), ('en ', 'mentor ', 'mentor '), ('en ', 'news ', 'news '), ('en ', 'advert ', 'advert '), ('en ', 'schedule ', 'schedule '), ('en ', 'schedule ', 'schedule '), ('en ', 'schedule ', 'schedule '), ('en ', 'schedule ', 'schedule '), ('en ', 'schedule ', 'schedule ')]
Обратите внимание, в каком виде ответ. Из файла я сразу получаю удобоваримый json, который могу отдавать в шаблонизатор.
Из базы мне еше нужно написать обработчик, который сконвертит список в json.
На DLE достаточно просто.
Натыкать кнопок?? Создать 2 шаблона и два языковых файла? Это вообще не SOLID 😀
Натыкать кнопок?? Создать 2 шаблона и два языковых файла? Это вообще не SOLID 😀
Почему не SOLID? Будет полнота действий без ограничений. Меняй как пожелаешь.
Кнопки для переключения языка можно в селекте натыкать.
Нет необходимости создавать языковые пакеты для версий DLE, они уже давно адаптированы под ru/en/uk, нужно просто подключить к каждому шабу.
А конкретно будущей редакции шаблонов, ничего сложного в этом не вижу, главное не запутаться.
DLE, они уже давно адаптированы под ru/en/uk
Sly32, слушай что люди говорят, они ж плохого не посоветуют, вот чего ты мучаешься с этим json, возьми DLE да и всё. Всё уже придумано, зачем велосипеды изобретать...
ЗЫ. Понимаешь теперь с чем мне приходилось сталкиваться?
во-вторых каждый раз при загрузке этих переводов будет парситься json, это тоже накладные расходы, по-хорошему надо или хранить в отдельных py файлах, чтобы далее сгенерировался байт код pyc или прикрутить компиляцию джейсона в py, а далее в pyc
А зачем json? Почему не обычный массив?