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

[zaartix]

вот собираю базу синонимов ключевых слов (к примеру yandex и яндекс), задумался над структурой бд. Первое что приходит на ум:

CREATE TABLE `a_syn` (
  `id` int(11) NOT NULL auto_increment, // id слова
  `pid` int(11) NOT NULL, // id родителя (оригинала для синонима)
  `w` varchar(32) NOT NULL, // само слово
  PRIMARY KEY  (`id`),
  UNIQUE KEY `w` (`w`),
  KEY `pid` (`pid`)
) ENGINE=MyISAM

Пример с яндексом будет такой:
1 | 0 | yandex
2 | 1 | яндекс
3 | 1 | яша

вот, какие будут мнения? может подводные камни такой структуры?

 

[gregzem]

Для практической полезности данной базы данных добавьте еще поля для хранения фонетической хеш-функций слова (Daitch-Mokotoff Soundex).

 

[zaartix]

Для просмотра ссылки Войди или Зарегистрируйся
об этом речь?

Если да - то какой тип поля взять? char(6) ?

для пущей уверенности надо еще и soundex как таковой юзать.
Когда сравнивал результаты работы, Daitch-Mokotoff иногда давал разные значения там, где soundex одинаковые давал. По логике это были одинаковые слова.

Насколько я понимаю soundex надо тоже в отдельное поле запихать? использовать штатную select * from table where soundex(field)='needle' не хочется, ведь он должен будет обойти все строки и посчитать им soundex, а так если использовать обычное индексное поле, то выборка должна быть быстрее в разы. Я прав?

 

[zaartix]

Вообще можно наверное вынести в отдельную тему:

Daitch-Mokotoff почитал одинаковыми слова:
описание==общение
заказ==секс
световой==свадьба
хостинг==гостиница
музыка==месяц
видео==фото

и это только по базе из 200 слов, имхо надо делать комплекс soundex + Daitch-Mokotoff, если оба совпадают - тогда уже все ок.
Правда при таких раскладах web-мастер != вэб-мастер, из-за того, что soundex не даст добро.

 

[gregzem]

Когда я занимался этими вопросами soundex не умел работать с русскими буквами, приходилось транслитерировать все слова. Как сейчас обстоят дела - не знаю.
По поводу типа данных для хранения - почему бы не VARCHAR?

 

[awp]

Связь реализованная прикольно, но для таблиц маленького объема - как пример для иерархического меню. Ты думал как ты будеш в запросах лопатить ГРОМАДНУЮ таблицу? На мой взгляд лучше разделить на 2 таблицы + создать индексы + дублировать головную запись в подчиненной таблице.

 

[venetu]

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

SELECT txt FROM synons  WHERE
  CONCAT('|',txt,'|') ULIKE '%|слово|%'

потом explode('|',$txt) - и вуаля. У нас в массивчике все синонимы для данного слова, а первый элемент массива - это основное слово.

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

Ну и ключ на полнотекстовый поиск на это поле, естественно.

 

[awp]

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

SELECT txt FROM synons  WHERE
  CONCAT('|',txt,'|') ULIKE '%|слово|%'

потом explode('|',$txt) - и вуаля. У нас в массивчике все синонимы для данного слова, а первый элемент массива - это основное слово.

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

Ну и ключ на полнотекстовый поиск на это поле, естественно.

Довольно оригинальный подход. Вопрос по стоимости выполнения такого запроса?

 

[venetu]

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

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

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

 

[akgrad]

Я бы тоже сделал две таблицы:

Таблица 1 - id слова и само слово
Id
Текст

Таблица 2 - связь между двумя id из первой таблицы
Id1
Id2

имхо - просто, понятно и быстро.