|
|
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Добрый день. Очень надеюсь на вашу помощь, поскольку нет понимания каким образом решать этот вопрос Есть первая таблица с номером поиска и делавшим его уникальным id Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Во второй таблице номер поиска и параметры которые он устанавливал при поиске: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Вопрос, как получить номер поиска если такой уже был у конкретного пользователя? Например, если поиск делает пользователь 111 и в поиске ставит параметры setting1 и setting3, то нужно получить 2. Возможно необходимо организовать по-другому таблицы? Буду очень благодарен за помощь. Если честно не знаю даже что искать в гугле, в каком направлении рыть, кроме как методом прямого перебора :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 04:15 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Ostap Smirnovпоиск делает пользователь 111 и в поиске ставит параметры setting1 и setting3, Код: sql 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 10:10 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
допустим сравнивать строку поиска с GROUP_CONCAT(setting) проблема в том что если изменить порядок в строке поиска, это не сработает. Значит это откинем. Вероятно лучше будет при "Например, если поиск делает пользователь 111 и в поиске ставит параметры setting1 и setting3, то нужно получить 2. " получить и 1 и 2 и дать человеку выбор, какой же поиск нужен. Если я понял правильно сие действо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 10:17 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Alex_Ustinovдопустим сравнивать строку поиска с GROUP_CONCAT(setting) проблема в том что если изменить порядок в строке поиска, это не сработает. Значит это откинем. Да, порядок может быть разный, поэтому откидываем :) Alex_UstinovВероятно лучше будет при "Например, если поиск делает пользователь 111 и в поиске ставит параметры setting1 и setting3, то нужно получить 2. " получить и 1 и 2 и дать человеку выбор, какой же поиск нужен. Если я понял правильно сие действо. Наверно не поняли :) В поиске 1 он искал по 3м параметрам, в которые входит setting1 и setting3, но там был еще один параметр и это другой поиск, который выдаст другие результаты... А нам нужно показать что именно этот поиск он уже выполнял, с именно этим набором параметров и если он ищет его постоянно, то предложить сохранить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 13:09 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
AkinaOstap Smirnovпоиск делает пользователь 111 и в поиске ставит параметры setting1 и setting3, Код: sql 1. 2. 3. 4. 5. 6. Увы много непонятных команд и я не понимаю почему, но у меня выдает Unknown column 'setting1' in 'where clause' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 13:11 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
AkinaOstap Smirnovпоиск делает пользователь 111 и в поиске ставит параметры setting1 и setting3, Код: sql 1. 2. 3. 4. 5. 6. Ага, кавычки не косые нужны, а прямые... Ответ вернулся неверный. С "DISTINCT" вернулись id_search в которых участвовал параметр setting1 и setting3, т.е. вернуло 1,2,3,5... Но они все искались разными пользователями. А нам нужно только те что делал пользователь "111". А без "DISTINCT" выдало пустой результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 14:12 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Ostap SmirnovAkinaпропущено... Код: sql 1. 2. 3. 4. 5. 6. Ага, кавычки не косые нужны, а прямые... Ответ вернулся неверный. С "DISTINCT" вернулись id_search в которых участвовал параметр setting1 и setting3, т.е. вернуло 1,2,3,5... Но они все искались разными пользователями. А нам нужно только те что делал пользователь "111". А без "DISTINCT" выдало пустой результат. ну та джойн таблицы где есть юзер айди, и добавить условие выборки для конкретного юзера. Я бы всетаки предложил , ввиду того что действо наверно частое, дабы избежать гроупбай, на каждые параметры поиска генерировать хеш (пусть даже мд5, или даже контрольную сумму срц32), и искать по нему, а потом уже уточнять. - но если сугубо фильтрация по пользователю, то этот критерий уже достаточно срежет таблицу, и там легко и групбай пройдёт, с другой стороны если сработает индекс по пользователю, то уже не сработает по хешу. это на случай, если нужно искать подобное без привязки к пользователю, либо на одного пользователя часто могут буть 1000чи разных вариантов поиска(что врядли). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 15:21 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 15:54 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Akina Код: sql 1. Вы просто чудо, а не человек :) Спасибо большое. Ничего не говорите, но предлагаете дельные решения. Вижу что двигаемся в нужном направлении... И вроде как после проверки данный запрос сработал, но если добавить еще один параметр, при котором должен быть пустой результат - получается непредсказуемо другой :) Смотрите, вот такой запрос (тот же пользователь ищет с еще одним параметром), по идее должен быть пустой результат, потому что такого поиска он еще не совершал: Код: sql 1. 2. 3. 4. 5. 6. Но нет, получаем 2 ответа: 2 и 3 . Почему так? И вроде как судя по конструкциям логически все должно уже работать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 17:44 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
alex564657498765453ну та джойн таблицы где есть юзер айди, и добавить условие выборки для конкретного юзера. Ээээээ... в эту выборку еще и джоин? У меня мозг взрывается когда я начинаю осмысливать эти джоины :( alex564657498765453Я бы всетаки предложил , ввиду того что действо наверно частое, дабы избежать гроупбай, на каждые параметры поиска генерировать хеш (пусть даже мд5, или даже контрольную сумму срц32), и искать по нему, а потом уже уточнять. - но если сугубо фильтрация по пользователю, то этот критерий уже достаточно срежет таблицу, и там легко и групбай пройдёт, с другой стороны если сработает индекс по пользователю, то уже не сработает по хешу. это на случай, если нужно искать подобное без привязки к пользователю, либо на одного пользователя часто могут буть 1000чи разных вариантов поиска(что врядли). Хм, а это интересный вариант... еще отсортировать setting , чтоб хэш совпадал и в принципе да, можно... Но вам не кажется что это все-таки уже как больше костыль, чем решение? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 17:49 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Ostap Smirnov , ну сделайте дубово: Код: sql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 18:00 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Ostap Smirnovв эту выборку еще и джоин? У меня мозг взрывается когда я начинаю осмысливать эти джоиныВ моём запросе есть INNER JOIN, просто он записан как декарт с отбором. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 18:01 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Akina Ostap Smirnov , ну сделайте дубово: Код: sql 1. 2. Код: sql 1. 2. 3. 4. 5. 6. 7. :( Тот же результат, 2 и 3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 18:44 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
КоличествоПараметров - это число. В данном случае - 3 (три). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 18:50 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Akina, а если вместо COUNT(search.setting) поставить 3 , то результат 3 , что тоже неверно :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 18:51 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Ostap Smirnov, Простите, есть такой результат, действительно 3 :) Спасибо. Сейчас буду проверять на других комбинациях. Еще раз спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2016, 18:53 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Ostap Smirnovalex564657498765453ну та джойн таблицы где есть юзер айди, и добавить условие выборки для конкретного юзера. Ээээээ... в эту выборку еще и джоин? У меня мозг взрывается когда я начинаю осмысливать эти джоины :( alex564657498765453Я бы всетаки предложил , ввиду того что действо наверно частое, дабы избежать гроупбай, на каждые параметры поиска генерировать хеш (пусть даже мд5, или даже контрольную сумму срц32), и искать по нему, а потом уже уточнять. - но если сугубо фильтрация по пользователю, то этот критерий уже достаточно срежет таблицу, и там легко и групбай пройдёт, с другой стороны если сработает индекс по пользователю, то уже не сработает по хешу. это на случай, если нужно искать подобное без привязки к пользователю, либо на одного пользователя часто могут буть 1000чи разных вариантов поиска(что врядли). Хм, а это интересный вариант... еще отсортировать setting , чтоб хэш совпадал и в принципе да, можно... Но вам не кажется что это все-таки уже как больше костыль, чем решение? ;) а есть другой вариант хешировать множество? (множество - набор без порядка следования) вы хоть понимаете что обычно называют костылём? называют решение, которое выглядит криво, дабы не переделывать существующую кривизну решения. тобишь костыль априори не может быть в новом коде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2016, 19:03 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Ostap Smirnov, но подчёркичаю, это если искать надо без привязки пользователя... тоесть что возможно ситуация групировки на тысячи/десятки-тысяч строк. если на 10-20 срок, групировка тоже быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2016, 19:07 |
|
||
|
Выборка из двух таблиц с совпадающими значениями из множества других
|
|||
|---|---|---|---|
|
#18+
Ostap SmirnovХм, а это интересный вариант... еще отсортировать setting , чтоб хэш совпадал и в принципе да, можно... Но вам не кажется что это все-таки уже как больше костыль, чем решение? ;) alex564657498765453а есть другой вариант хешировать множество? (множество - набор без порядка следования) вы хоть понимаете что обычно называют костылём? называют решение, которое выглядит криво, дабы не переделывать существующую кривизну решения. тобишь костыль априори не может быть в новом коде. Хешировать множество по другому? Немного не понял вопроса. Я так понимаю что если не отсортировать, то хеш будет разный, поэтому только сортировать... Хотя это я просто повторяю что 2*2=4. Про формулировку "костылей" я не задумывался ;) Но вы правы, в моей фразе правильнее было бы использовать фразу "кривое решение". alex564657498765453но подчёркичаю, это если искать надо без привязки пользователя... тоесть что возможно ситуация групировки на тысячи/десятки-тысяч строк. если на 10-20 срок, групировка тоже быстро. В моем случае мне необходим такой поиск только с привязкой к пользователю. Плюс база не планируется быть на десятки тысяч строк... Я реализовал решение Akina и оно работает. И как говориться, если работает - не трогай :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2016, 18:05 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39311354&tid=1831389]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
166ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
| others: | 224ms |
| total: | 462ms |

| 0 / 0 |
