[mysql] структура бд для хранения синонимов

Статус
В этой теме нельзя размещать новые ответы.
gregzem
как не умел, так и не умеет. Тут главное - корректная транслитерация
venetu
я бы сделал проще. Выбрал бы символ, который точно не встречается в словах, например, '|', и записывал бы в таблицу все синонимы в одно текстовое поле через этот символ. Отдельно во второе поле можно вставлять символ-оригинал. Можно его же хранить тоже в этом текстовом поле, просто ставить первым. Итого, чтоб найти все синонимы к твоему слову, надо сделать такой вот селект:

Code:
SELECT txt FROM synons WHERE
CONCAT('|',txt,'|') ULIKE '%|слово|%'
потом explode('|',$txt) - и вуаля. У нас в массивчике все синонимы для данного слова, а первый элемент массива - это основное слово.

Чтоб не делать CONCAT при каждом селекте, можно в начало и конец txt добавлять '|' перед записью в базу и там хранить.

Ну и ключ на полнотекстовый поиск на это поле, естественно.
если и делать так, то уж точно не через спец-символ. serialize для чего людам дан? А вообще этот запрос будет гораздо тяжелее, нежели мой, поэтому отпадает
А не факт, что будет медленнее, чем с иерархической структурой. С одной стороны у тебя строки длинные получаются, +полнотекстовый поиск и все дела, а с другой - сама структура таблицы в разы проще, и кол-во записей в ней меньше, и вообще..

Судя по тому, с какой скоростью работает обычный поиск по сайту (а это и есть поиск по ключевому слову, только таблица самая простая какая может быть) против скорости выборки сложными запросами чисел (мало данных, много связей) я лично голосую за этот способ, мне кажется будет быстрее. Опять же, по этому полю есть индекс - значит мускулу вообще работы не остается практически. Должно просто летать :)

Ну а с тем, что данный способ намного проще в реализации - я думаю никто и так спорить не станет. Так что делай так, если вдруг начнет тормозить - вот тогда и будешь чесать репу. А пока - "Не тратьте время на решение проблем, которых у вас нет" (с)
а вот тут возникает вопрос, у вас какой опыт работы с бд? имеется ввиду в реальной жизни, когда проекты становятся популярными (читай - дохрена запросов к бд в секунду)?
Я это к тому, что полнотекстовый индекс - это самый крайний вариант.
Индекс хорош только для выборок, но если в табилцу часто идут инсерты или апдейты - имеет смысл просчитать целесообразность каждого индекса, и уж тем более полнотекстового.
Не тратьте время на решение проблем, которых у вас нет
если бы мы с вами говорили за жизнь, то согласился-бы, а в программировании это бред полнейший, который сводит на нет само понятие оптимизации.
 
если и делать так, то уж точно не через спец-символ. serialize для чего людам дан?
На сериалайзнутые данные потом сложнее ставить условия в select'е, только и всего. Я ж предлагаю не просто джоинить, а еще и мало-мальски подготавливать их именно с целью упростить последующие выборки.

а вот тут возникает вопрос, у вас какой опыт работы с бд? имеется ввиду в реальной жизни, когда проекты становятся популярными (читай - дохрена запросов к бд в секунду)?

Да, действительно. Сразу видно, что в этой таблице данные находятся не в нормальной форме. В универе на теории БД меня учили никода ни в коем случае так не делать. И я долгое время не делал. Но однажды пришлось переступить через себя - сервак окончательно загибался и надо было срочно что-то менять в структуре. Скопировали данные в две таблицы - и сразу избавились от кучи лишних селектов, все зашуршало намного быстрее.

А позже выяснил, что дублирование данных и вынос их из внешней таблицы в основную - довольно частая вещь в вебдеве. И ничего грешного в этом нет. Посмотри на исходники того же LiveJournal - там далеко не все правильно с точки зрения организации БД. Но я уверен, каждое решение у них принималось более чем взвешенно, и раз уж они не используют НФ, то это вовсе не по незнанию.

если бы мы с вами говорили за жизнь, то согласился-бы, а в программировании это бред полнейший, который сводит на нет само понятие оптимизации.

Ранняя оптимизация приводит к потере времени. (с) не я.
Сначала тестируем - потом оптимизируем.

Ну и расскажи в итоге, на какой структуре остановился? Или все выбираешь? Уже ж 2 недели прошло, небось уже давным-давно все сделал, а топик просто так поддерживаешь. :) Или нет?
 
остановился на той, что предложил в самом начале. Открытым остался вопрос с soundex и Daitch-Mokotoff, но это уже только тестить
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху