Тэги – неотъемлемая часть всех современных сайтов и косвенный признак принадлежности сайта к пресловутому Вэб-Два-Ноль.
В статье я хочу рассказать об способах и алгоритмах тегирования информации.
Итак, при организации тэгов существует несколько слабых и узких мест, а именно:
К сожалению, универсальный алгоритм, который легко бы решал все эти проблемы автору не знаком. Далее о самих алгоритмах.
Существует огромная таблица с тэгами, существуют огромные таблицы с тегируемой информацией. Связь между ними осуществляется через третью таблицу, которая получается очень большого размера. Так, если статей у нас 50000, а тэгов 10000, при условии что каждая статья в среднем связана с 4-мя тэгами, получаем размер таблицы в 200000.
Плюсы:
Алгоритм приведен в моей статье «Полнотекстовый поиск и его возможности»
Теперь о том, как это делается непосредственно по отношению к тэгам. В поле с полнотекстовым индексом лежат сами тэги в том виде, как они были записаны. Выборка объектов происходит исключительно по этому полю. Исходя из этого же поля строится принадлежность объекта к тэгам. Это означает, что если тэг русский, то и ссылка на него должна содержать русские буквы. А с этим возникают проблемы, т.к. они могут кодироваться c помощью urlencode, а это зависит уже от кодировки. Т.е. один и тот же тэг в зависимости от того, в какой кодировки страница, должен быть декодирован по-разному. Можно конечно использовать транслит русских слов в английские, и в писать их в поле наряду с русским словами. Тогда тэг будет отображаться на русском, а ссылка на него будет в латинице, и поиск будет идти тоже в латинице. Плохой выход, но выход.
Плюсы:
Если кто-то знает еще варианты организации – будет интересно о них узнать. Конструктивная критика приветствуется.
В статье я хочу рассказать об способах и алгоритмах тегирования информации.
Итак, при организации тэгов существует несколько слабых и узких мест, а именно:
- добавление и изменение принадлежности тэгов к объекту.
- создание и изменение самих тэгов.
- отображение тэгов на старице.
- поиск по тэгам.
- назначение алиасов тега
- построение облака тегов
К сожалению, универсальный алгоритм, который легко бы решал все эти проблемы автору не знаком. Далее о самих алгоритмах.
Нормальное соотношение многое-ко-многим.
Существует огромная таблица с тэгами, существуют огромные таблицы с тегируемой информацией. Связь между ними осуществляется через третью таблицу, которая получается очень большого размера. Так, если статей у нас 50000, а тэгов 10000, при условии что каждая статья в среднем связана с 4-мя тэгами, получаем размер таблицы в 200000.
Плюсы:
- нет проблем с построением облака тэгов
- нет проблем с алиасами.
- нет проблем с созданием и изменением тэгов
- нет проблем с «выпадающим списком тэгов»
- добавление и изменение принадлежности тэгов к объекту затрудненно, поскольку требуется отдельный INSERT или DELETE на каждую изменяемую связь. Еще нужен INSERT при создании тэга. Если некоторые тэги в единственном числе (что часто бывает), то они будут оттягивать на себя ресурсы (увеличивая размеры таблиц), не неся при этом почти никакой практической пользы.
- получение и отображение тэгов требует JOIN-объединение 3-х огромных таблиц. Из примера выше: таблица в 50000 join таблица 200000 join таблица 10000. Это будет работать медленно уже с этими данными. Учитывая то, что реально требуется сделать join еще 2-3 большие таблицы (например, таблицу пользоватлей и таблицу рейтинга), получается совсем не радужная картина. Да, я в курсе, что можно кэшировать, но сейчас не об этом.
- поиск по тэгам требует опять объединения больших таблиц
С помощью полнотекстового поиска
Алгоритм приведен в моей статье «Полнотекстовый поиск и его возможности»
Теперь о том, как это делается непосредственно по отношению к тэгам. В поле с полнотекстовым индексом лежат сами тэги в том виде, как они были записаны. Выборка объектов происходит исключительно по этому полю. Исходя из этого же поля строится принадлежность объекта к тэгам. Это означает, что если тэг русский, то и ссылка на него должна содержать русские буквы. А с этим возникают проблемы, т.к. они могут кодироваться c помощью urlencode, а это зависит уже от кодировки. Т.е. один и тот же тэг в зависимости от того, в какой кодировки страница, должен быть декодирован по-разному. Можно конечно использовать транслит русских слов в английские, и в писать их в поле наряду с русским словами. Тогда тэг будет отображаться на русском, а ссылка на него будет в латинице, и поиск будет идти тоже в латинице. Плохой выход, но выход.
Плюсы:
- нет проблем с выводом тэгов
- нет проблем с поиском по тэгам
- нет проблем добавлением и изменением принадлежности тэгов к объекту
- нет проблем с алиасами (точнее есть, но они решаемы)
- отпадает проблема создания тэга
- легко можно делать поиск не по одному, а по нескольким тэгам, а так же вычислять похожие материалы
- переименовать или удалить тэг просто так не получится, это требуется в полях всех объектов, которыми назначены тэги
- с построением облака тегов очень большие проблемы. Можно решить так: обрабатываются все «тэговые» поля таблиц, анализируется частота присутствия отдельного тэга (эх, был бы доступ непосредственно к самому полнотекстовому индексу, как было бы хорошо) и на фоне этого строится облако. После чего кэшируется на длительный промежуток времени.
- сложно сделать «выпадающий список тэгов»
Если кто-то знает еще варианты организации – будет интересно о них узнать. Конструктивная критика приветствуется.
