|
|
|
MySQL-запрос в зависимости от кол-ва найденных записей
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Возникла такая задача: на странице товара - выводить 4 похожих товара. Эта самая "похожесть" будет определяться так: 1. В первую очередь - проверяем на марку, модель, год. 2. Если ничего нет - проверяем только на марку и модель. 3. Если и сочетания марки и модели нет - проверяем только на марку. Делаю так: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. Работает-то оно работает, но блин сам подход дебильный. Индия какая-то... Тем более, если у меня будет не 3 а штук 7 параметров совпадения - это кучу вложенных условий придётся лепить. Есть какие идеи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2014, 12:32:36 |
|
||
|
MySQL-запрос в зависимости от кол-ва найденных записей
|
|||
|---|---|---|---|
|
#18+
Можно попробовать так Код: sql 1. 2. 3. , но будет ли это лучше по скорости, даже учитывая, что это один селект вместо трёх - большой вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2014, 12:40:21 |
|
||
|
MySQL-запрос в зависимости от кол-ва найденных записей
|
|||
|---|---|---|---|
|
#18+
tanglir, Ммм, а вы думаете что в вашем примере - мускул сам остановится при 1-м же нахождении не нулевого результата и выдаст мне максимальный? Ну всмысле, если будет хоть 1 совпадение по МАРКА+МОДЕЛЬ - он тут же их мне выпленет, и не станет искать только по марке? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2014, 13:00:54 |
|
||
|
MySQL-запрос в зависимости от кол-ва найденных записей
|
|||
|---|---|---|---|
|
#18+
iova1984выводить 4 похожих товара. Эта самая "похожесть" будет определяться так: 1. В первую очередь - проверяем на марку, модель, год. 2. Если ничего нет - проверяем только на марку и модель. 3. Если и сочетания марки и модели нет - проверяем только на марку. Делаю так: Если по первому пункту будет 2 совпадения - то у тебя 2 и выведется, хотя по смыслу сказанного надо бы ещё добавить 2 совпадающих по второму пункту... или нет? если да - то надо корректировать LIMIT в текстах запросов второго-третьего пунктов. Но вообще идея правильная - вот только её реализация так себе. Надо наборы критериев по пунктам слить в массив и в цикле обрабатывать, пока не наберётся необходимое для вывода количество записей или пока список наборов критериев не кончится. Тогда пофиг будет, три набора критериев или семь... и да - вынести всё это на сервер в форме хранимой процедуры, неча на клиенте держать бизнес-логику. Один же запрос с сортировками на более-менее приличной таблице - это тормозилово будет, к гадалке не ходи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2014, 13:40:16 |
|
||
|
MySQL-запрос в зависимости от кол-ва найденных записей
|
|||
|---|---|---|---|
|
#18+
iova1984Есть какие идеи? поскольку таблица товаров обновляется редко, а запросов с рендером рекомендаций <очень много>, то мы в таких случаях пишем кнопку для контент-менеджера и когда она поработала с каталогом, то нажав её отдельной обработкой проходимся по всей таблице и заполняем поле рекомендаций, куда вставляем список идентификаторов рекомендуемых товаров это решение позволяет существенно экономить вычислительные ресурсы, увеличивает скорость и при этом остается гибкость изменения правил рекомендации - просто нажать кнопку пересчета по всей базе и готово, код рендера при этом не трогается вообще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.09.2014, 15:56:57 |
|
||
|
MySQL-запрос в зависимости от кол-ва найденных записей
|
|||
|---|---|---|---|
|
#18+
iova1984а вы думаете что в вашем примере - мускул сам остановится при 1-м же нахождении не нулевого результата и выдаст мне максимальный?нет, потому и написал, что скорости ждать не придётся ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2014, 07:04:32 |
|
||
|
MySQL-запрос в зависимости от кол-ва найденных записей
|
|||
|---|---|---|---|
|
#18+
Lumixiova1984Есть какие идеи? поскольку таблица товаров обновляется редко, а запросов с рендером рекомендаций <очень много>, то мы в таких случаях пишем кнопку для контент-менеджера и когда она поработала с каталогом, то нажав её отдельной обработкой проходимся по всей таблице и заполняем поле рекомендаций, куда вставляем список идентификаторов рекомендуемых товаров это решение позволяет существенно экономить вычислительные ресурсы, увеличивает скорость и при этом остается гибкость изменения правил рекомендации - просто нажать кнопку пересчета по всей базе и готово, код рендера при этом не трогается вообще Обновляется как раз часто - пуд товарами подразумеваются автомобили. Доска объявлений по продаже авто. До 300 объявлений в сутки добавляется, примерно столько же удаляется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2014, 09:43:54 |
|
||
|
MySQL-запрос в зависимости от кол-ва найденных записей
|
|||
|---|---|---|---|
|
#18+
iova1984tanglir, Ммм, а вы думаете что в вашем примере - мускул сам остановится при 1-м же нахождении не нулевого результата и выдаст мне максимальный? Ну всмысле, если будет хоть 1 совпадение по МАРКА+МОДЕЛЬ - он тут же их мне выпленет, и не станет искать только по марке? нет конечно. Ты попробуй, да ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2014, 12:13:54 |
|
||
|
MySQL-запрос в зависимости от кол-ва найденных записей
|
|||
|---|---|---|---|
|
#18+
iova1984Обновляется как раз часто - пуд товарами подразумеваются автомобили. Доска объявлений по продаже авто. До 300 объявлений в сутки добавляется, примерно столько же удаляется. 300 обновлений в сутки это редко потому что показов с рекомендациями происходит 300 в секунду поэтому такое обновление (перерасчет) можно делать по хрону раз в 15 минут и ничего страшного, что по нескольким новым машинам не будут показываться рекомендации в течение 5-10 минут с момента публикации можно вообще только раз в сутки пересчитывать за счет отдельных пересчетов порой удается тупо освободить несколько серверов, если речь идет о посещаемом сервисе, а удобство для пользователей остается таким же... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.09.2014, 13:17:00 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38741612&tid=1834248]: |
0ms |
get settings: |
5ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
53ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 198ms |
| total: | 364ms |

| 0 / 0 |
