Тема берет своё начало тут - viewtopic.php?f=20&t=51139&p=407154 Вообще что я делаю, есть записи у них есть теги и мне надо организовать поиск по тегам, записей много. изначально я использовал принцип из WP, т.е. 3 таблицы, первая записи (post_id, post_text), вторая теги (tag_id, tag_name) и третья собственно связи между записями и тегами (rs_id, post_id, tag_id), но у данного поиска свои недостатки, я решил изменить архитектуру и оставить 2 таблицы первая записи, в нее мы добавляем теги (post_id, post_text, post_ tags) и вторая (tag_id, tag_name) и собственно запись выглядит так: post_id 1 post_text '.....' post_ tags '"1", "5", "100", "12", "33"' В post_ tags идут через запятую tag_id и они берутся в кавычки для более точного поиска (LIKE '%"5"%') при поиске я указываю какие обязательно должны быть теги т.е. LIKE '%"5"%' AND LIKE '%"100"%' указываю какие теги желательно что бы были LIKE '%"12"%' OR LIKE '%"33"%' OR LIKE '%"1"%' так же могу задать теги которых не должно быть NOT LIKE. Все хорошо, только вот возникла проблема с сортировкой, мне надо что бы чем больше желательных тегов присутствует, тем запись выше было в списке, т.е. если я делаю поиск LIKE '%"12"%' OR LIKE '%"33"%' OR LIKE '%"1"%', если в записи есть все 3 тега, то она идет первая, если 2 тега то вторая, а если 1 то последняя, примерно как то так. Можно ли как то такое организовать?
не, нельзя. у тебя неправильная архитектура. ну это просто потому что ты ничего не читал и ничего не понимал. просто слепил наспех. а теперь проблемы от того что у тебя велосипед с квадратными колесами не едет. ну прям грустьпичяль, да.
И еще в нагрузку вопрос, суть задачи описана выше, точный поиск по тегам по всевозможным вариантам (обязательно должно быть, желательно что бы было и что бы не было) как еще можно организовать все это.
причем знаешь что самое интересное. ты взял велосипед с круглыми колесами, тебе что-то в нем не понравилось. но что именно ты не понял ибо ты нифига не знаешь, напомню. поставил квадратные колеса и побежал на форум ныть что не едет. вот прям не знаю даже. поставь круглые колеса. помог советом? ну раз учиться ты не хочешь. буду стебать тебя очевидными вещами чо уж. Добавлено спустя 53 секунды: а на русский язык можно это предложение переводить обычный читатель сложно понимание
Могу порекомендовать книгу прочитать по реляционных баз данных. Поиск по тегам можно через sphinx реализовать.
если следовать его логике брать готовое решение и ломать то книгу он не прочитает а свою напишет. и не поймет в ней нихера...
Ну так я пытаюсь сам додумать как организовать все это, а не иду в раздел "сделай за меня", тем более я подобный подход вычитал на каком то форуме, там вроде как про квадратные колеса ни слова не было правда там и про столько изощренный поиск тоже речь не шла. И все же как тогда подобное можно организовать?
херовый ты специалист. не должно быть таких вопросов. смекалки ноль, знаний ноль. только дай-дай-дай. зебра.
VLK Есть теория реляционных баз данных, когда их прочитаешь и поймёшь, тогда сам и сможешь додумать как всё правильно сделать. Я так понимаю книгу читать ты не будешь?
Почему, буду, но не сейчас, сейчас мне надо сделать, хоть кое как, все равно скажем так это для личного пользования, т.е. ни кто больше не пострадает Вот и ищу варианты, я конечно внутренне понимаю что что-то в моём варианте не то
Так если для себя и оно работает, зачем переделывать? Для поиска можешь посмотреть sphinx, elasticsearch.
Вам прямой путь к полнотекстовому поиску. Количество совпадений там вроде как нет (в innodb), а по релевантности - да. Читайте доку - там показано как сделать. Если нужно именно по количеству, то нужен другой вариант. Лучше всего с отдельной таблицей тегов. п.с. like '%...%' допустимо только на маленьких таблицах, ибо это полнотабличный скан (медленно).
там есть некоторые косяки, что то типа нет возможности использовать LIMIT, не в прямом смысле, а в переносном (по крайне мере я не знаю как это замутить) Второй косяк большой объем данных, иногда страница не успевает обработать, выходит отведенные 180 сек. Заглянул по совету в FULLTEXT, подходящий вариант это IN BOOLEAN MODE.
ты упоротый. вместо того чтоб пойти почитать ты налево и направо рассказываешь что ты нифига не знаешь. стало быть либо архитектура не та либо ты не так что-то делаешь. и мы об этом не узнаем потому что ты ничего не сможешь рассказать потому что ты ходишь и рассказываешь что ты нифига не знаешь.
программист отесывается годами... ты торопишься куда-то? деньги мимо тебя пролетают что ли? пожар? самолет?
Да, насчет sphinx, это надо ставить, это надо вникать, а мне надо чем быстрее тем лучше, да и не особо надо что бы все было супер но хотелось бы что бы все было как можно лучше Вот я и думал решить абы как, но по быстрому, через LIKE, хотя это квадратные колеса ну или FULLTEXT, но к сожаление это оказалось не совсем возможно, одним словом в моем случает, от чего пытался уйти к тому же и приходил только с другой стороны По этому буду допиливать что есть, скорее всего через 3 таблицы. Всем спасибо за помощь.
у него нет этих 20 минут. он не бурильщик-нефтяник которого за бокалом пива в космонавта обратили чтоб метеориты бурить. у него всё еще быстрее должно быть. как у супермэна. как нео посмотрел картинку и уже знает боевое искусство. как лилу посмотрела пару кадров и знакома со всей историей человечества. как школота которому учиться программированию не хочется а писать самостоятельно утилиты уровня операционной системы - надо. в мире столько бабулеса мимо его рук проплывет пока он 20 минут тратит на ознакомление со сраным сфинксом.
Проклятый Сфинкс!!11 Ты встал на моём пути к мировому господству!!1 ( я тоже ) На самом деле Сфинкс простой как палка. Там конфиг, в конфиге описано что брать из бд (просто запрос), где там уникальный ключ (айдишник обычно) и что делать с полученными полями. Усё. Потом можно у Сфинкса спрость, в каких строках встречаются такое слово например. Он скажет уникальный ключ. Идёшь в бд, достаёшь строки. Усё.