elmar1o: Если я правильно понял, вопрос стоит так: Вы хотите оптимизировать страницы сайта под слово «купить», и не знаете будут ли вам в этом полезны кнопки с надписью купить.
Лучше оптимизировать заголовки, теги и текст, а кнопки вероятно дадут переспам.
а надо как-то скрипт так доработать, чтобы при запросе пользователей он и запускался... вызывает большое сомнение, что у вас такой поток пользователей, что эта часть требует серьезной оптимизации.
_SP_: Мощно... т.е. вы не можете найти элемент в массиве, и для этого 100.000 раз гоняете запросы к БД :) ? Гуглите "поиск элемента в массиве "язык"".
Если речь о массиве из 2000 элементов, то можно попробовать и перебором, всё равно должно быть быстрее чем с БД. Если массив большой, то придется использовать нормальный поиск (сортировать к примеру, а далее делением пополам) Если массив огромный, в сотни тысяч-миллионы записей, то тут да - придется использовать БД.
Вы изначально какую-то "муть" делаете... что-то у вас изначально в идее порочное. Даже если это "заранее прогретый кеш", то непонятно всё-равно зачем к БД с 2000 строк делать 100.000 запросов. Это не может быть нормальным её использованием. Если у вас 100.000 инсертов, то яб подумал о том, чтобы генерить скрипт с ними, а затем его исполнять "в одну транзакцию". (ну или порезать кусками по 10к, смотря как быстрее будет получаться)
Любитель. Этим занимаюсь не профессионально. У меня другая работа. Ну, это так, к слову))
А вообще я выше написал же, кол-во запросов минимизировал до 8тыс, просто не перемешиваю все характеристики товаров, чтобы не делать запросы, ответы на которые точно =0 товаров, а перемешиваю только характристики отдельно взятого товара (и так в цикле), потом уже из этого скомбинировал запросы, на которые точно есть как минимум один ответ.
Про "порочное" со 100тыс запросов -согласен. Я же понимаю ,что 100тыс запросов (в фильтрах) даже юзеры на сайте не сделают за 2 месяца.
NothingMatters: Так я и говорю: зачем делать эти запросы? У тебя всего 2к товаров. 1 запросом забираешь их из БД и делаешь туже самую фильтрацию на стороне скрипта, а затем результаты (ID товаров подходящих под фильтр) записываешь куда тебе нужно батчами. В итоге у тебя вместо 100к запросов будет 1 на выборку и штук 10 батчей на запись.
Я видимо чего то не знаю.
Вернее, я понимаю, что можно взять все товары из бд, закинуть данные по массивам....
Если я правильно понял, вопрос стоит так: Вы хотите оптимизировать страницы сайта под слово «купить», и не знаете будут ли вам в этом полезны кнопки с надписью купить.
Лучше оптимизировать заголовки, теги и текст, а кнопки вероятно дадут переспам.
Я тоже вопрос ТС-а также понял.
Но ведь Яндекс сам пишет https://yandex.ru/support/metrika/important/buy-button.html
Или они говорят размещайте, но не говорят, что будет переспам и пессимизация?
а чего вебмастеровский инструмент говорит?
Не понимают они эту разметку. Я задал вопрос в Я и получил ответ.
Неужели у вас на страницах дублируется только код калькулятора?
Ребят, спасибо. Ну что тут сказать - самоучка.
Буду развиваться и изучать, то что вы написали.
............
пока могу сказать только - надо. тестирую новый вариант.
их увеличится вдвое, т.к. добавится ещё пара характеристик фильтрации. Попробую сделать через массивы.
Он так сейчас для пользователей и работает...
Спасибо.
тему можно закрыть.
Мощно... т.е. вы не можете найти элемент в массиве, и для этого 100.000 раз гоняете запросы к БД :) ?
Гуглите "поиск элемента в массиве "язык"".
Если речь о массиве из 2000 элементов, то можно попробовать и перебором, всё равно должно быть быстрее чем с БД.
Если массив большой, то придется использовать нормальный поиск (сортировать к примеру, а далее делением пополам)
Если массив огромный, в сотни тысяч-миллионы записей, то тут да - придется использовать БД.
Вы изначально какую-то "муть" делаете... что-то у вас изначально в идее порочное.
Даже если это "заранее прогретый кеш", то непонятно всё-равно зачем к БД с 2000 строк делать 100.000 запросов.
Это не может быть нормальным её использованием.
Если у вас 100.000 инсертов, то яб подумал о том, чтобы генерить скрипт с ними, а затем его исполнять "в одну транзакцию".
(ну или порезать кусками по 10к, смотря как быстрее будет получаться)
Любитель. Этим занимаюсь не профессионально. У меня другая работа. Ну, это так, к слову))
А вообще я выше написал же, кол-во запросов минимизировал до 8тыс, просто не перемешиваю все характеристики товаров, чтобы не делать запросы, ответы на которые точно =0 товаров, а перемешиваю только характристики отдельно взятого товара (и так в цикле), потом уже из этого скомбинировал запросы, на которые точно есть как минимум один ответ.
Про "порочное" со 100тыс запросов -согласен. Я же понимаю ,что 100тыс запросов (в фильтрах) даже юзеры на сайте не сделают за 2 месяца.
Так я и говорю: зачем делать эти запросы?
У тебя всего 2к товаров. 1 запросом забираешь их из БД и делаешь туже самую фильтрацию на стороне скрипта, а затем результаты (ID товаров подходящих под фильтр) записываешь куда тебе нужно батчами.
В итоге у тебя вместо 100к запросов будет 1 на выборку и штук 10 батчей на запись.
Я видимо чего то не знаю.
Вернее, я понимаю, что можно взять все товары из бд, закинуть данные по массивам....
$massid[] = айди
$masszvet[] = цвет
$massrazmer[] = размер
$masstype[] = типа
ну либо через многомерный массив
$mass[] = array("id"==>"айди", "zvet"==>"цвет", "razmer"==>"размер" );
далее есть список вариантов запросов, в массиве $massvariantov
foreach ($massvariantov as $value) {
Но я не придумал, как из массивов делать выборку аналогично запросу к базе - where соблюдены_условия_такие_то
}
Не вижу смысла делать сотни тысяч запросов тут.
100тыс запросов, это вообще все возможные комбинации фильтра.
Понимаете от куда такое число?
NothingMatters, не кешировать. Записываем в бд id товаров соответствующих тому или иному варианту фильтрации товара.
Когда юзер фильтранул, просто берем список id из БД соответствующих его запросу.
Есть основания так сделать заранее (запись в бд). Пока что не хотел бы их (основания) разглашать. В тестировании.
Понимаю, что "на лету" это все просто формируется...