Зачем ты про севлада так? Он у нас умный парень, парсит юзерагент чтобы добавить поддержку webp.
Вроде сама интеграция GA + BigQuery возможна только при использовании GA360, которая в свою очередь стоит 150к в год. Партнеры получают по своим ценам, поэтому в стоимость могут включать ещё интеграцию. Мне кажется на таких цифрах вряд ли кто-то сдемпингует, особенно учитывая что в договоре скорее всего сказано что цена продажи не должна быть ниже какой-то определенной цены.
Тут нужно еще 2 инфлюенсера, опен-спейс дизайнер, смузи-мейкер, фистинг-рейпер, рэг-флор-клинер, дог вотчмен.
Конечно есть, на 500 строках даже индексы скорее всего не будут использованы.
Все зависит от дизайна.
CREATE TABLE product( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, name VARCHAR(255) NOT NULL DEFAULT '');CREATE TABLE category( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, parent_id INT UNSIGNED, name VARCHAR(255) NOT NULL DEFAULT '', include_sub_categories BIT(1) NOT NULL DEFAULT 0);-- design #1 --CREATE TABLE product_category_flat( category_id INT UNSIGNED, product_id INT UNSIGNED, sort INT NOT NULL DEFAULT 0, PRIMARY KEY (category_id, product_id));-- design #2CREATE TABLE product_category_parent( category_id INT UNSIGNED, product_id INT UNSIGNED, sort INT NOT NULL DEFAULT 0, PRIMARY KEY (category_id, product_id));
Сами таблицы одинаковы. Но они содержат разные данные.
Первый product_category_flat в тупую добавляет товары в категорию, если у родителя установили include_sub_categories, нужно взять товары всех подкатегорий, и добавить в родителя.
Или
Взять другой дизайн product_category_parent, где при выборке товаров из категории, при наличии include_sub_categories = 1 у родителя, мы вынуждены ещё получить эти подкатегории, затем получить товары включая подкатегории, и только тогда вывести их. А сам запрос превращается в SELECT DISTINCT(product_id) FROM product_category_parent WHERE category_id IN (...)
Это реальный пример из реального проекта на CMS, ко мне обращались люди, у которых листинг товаров грузился по 12 секунд. 12 секунд, Карл! Виновников было много, начиная с плагинов, которые возвращают по 40к строк зачем-то, заканчивая отсутствующими индексами. Конкретно пример выше позволял делать три запроса быстрее, один из которых на тот момент выполнялся за 0.531 секунд, после смены структуры стал выполнятся за 0.003 сек. На самом деле, смены структуры не было (делали на тестовом сервере), потому что это сломало бы все обновления. Поэтому терпят до сих пор.
Хорошо, и зачем определять UA, если есть Accept и тег Picture. У тебя индийские корни?
Напиши так, чтобы твои слова понял кто-то кроме тебя самого.
Рассказываю секрет: можно проверить, есть ли webp версия файла, если её нет - то сгенерировать, положить рядом, и отдать в ответе. В последующие разы, сразу будет отдаваться готовый файл. Это называется ленивая подготовка данных. И это умеет делать даже nginx.
Ты утомительный парень. Хоть бы раз признал что ступил.
Aisamiery, речь про магазин на 500-1000 товаров. Зачем там очереди и шардинг, если это не маркет-плейс по продаже наркотиков?
Маня, ты два часа назад писал что нужно парсить User-Agent. Переобулся?
Я подозревал о твоих ограниченых способностях, но не думал, что для тебя такое не возможно. Тогда да, лучше конечно на jpg сидеть и не дергаться.
Да, разработчиков, умеющих в ленивую конвертацию в webp нужно расстреливать. Вообще всех умных людей нужно расстреливать, Пол Пот ты наш.
99.(99)% что твой род деятельности был выбран не правильно.
Во-первых, браузер в запросе шлет заголовок Accept, в котором перечисляет какие форматы картинок он поддерживает.
И если там есть image/webp, то можно отвечать картинкой webp. На самом деле, у webp плюсы не только в размерах.
Во-вторых, делается через тег picture, и браузер сам выберет какую картинку ему забирать.
В-третьих, кто запрещает не включать в бекапы webp, и если уж придеться развернуться из бекапа, то пусть картинки генерируются на лету?
У меня по цифрам 90% браузеров уже забирают webp картинки. Разница со сжатым png, не сжатым png и webp можно глянуть на скрине:
От тебя не особо.
