Mysql, реализация тегов-тэгов-тагов

Подскажите, пожалуйста, как лучше.

1 вариант: 1 таблица, поля - ИД объекта (к которому теги), сам тег текстом
2 вариант: 2 таблицы, 1ая - уник ИД, тег текстом (уникальный); 2ая таблица - ИД объекта, ИД тега из 1ой

Какой вариант выбрать?

Спасибо.

я выбрал 2й вариант, но у меня десятки миллионов записей.

если записей 10-100к - лучше вариант 1

ps: все поля нужно сделать ключами/индексами, текстовые в том числе.

тоже за второй вариант, он производительнее при большом количестве записей

второй вариант надо делать только насколько я знаю, это принцип релевантых баз данных

Второй. Это и есть "нормализация"

Смотрел 5 опенсорс проектов 2.0, типа дигг, во всех реализован 1ый вариант. Второй видел только один раз, и то этот скрипт найти у себя не могу.

gimcnuk писал:

Смотрел 5 опенсорс проектов 2.0, типа дигг, во всех реализован 1ый вариант. Второй видел только один раз, и то этот скрипт найти у себя не могу.

А ты бы смотрел нормальный оупенсорс проект, который инженеры грамотные делали. Тот же hibernate.

2 вариант
универсальнее

Второй вариант теоретически более правильный.

А в конечном результате все равно от задачи будет зависеть. К примеру вариант 1, на поле с тегами кидаем full-text search индекс, и в результате по тегам ищем простым селектом, а не с нескольких таблиц. Ну а теги скажем отрабатываются ночью по крону, где вся их карта и статистика будет секунд за 5-10 сделана.

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

бОльшая часть запросов в варианте "2" сводится к 2м запросам, вместо одного (в варианте /1/). Но оба запроса будут выборкой по INT индексу.

Я еще раз скажу - у меня 120 млн записей только в одной таблице, 8 млн во второй и еще 4 млн в третьей - вариант (2) работает моментально.

ps: 2й способ так же решает много проблем, если нужно выводить облако тегов с числом сайтов в каждом из них.

ps2: вариант Stek-a c fulltext поиском не применим для больших объемов данных. Правда, по его словам, сайтов с большими базами почти нет..

Цитата:

вариант Stek-a c fulltext поиском не применим для больших объемов данных.

Почему ? Поискал в инете информацию о ограничениях, ничего подобного не нашел. Да и сам mysql позиционирует этот индекс как раз для поиска по тексту.

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

а) потому что размер индекса нужно минимизировать. а fulltext - это худший способ сделать это.

б) использование fulltext индекса для тегов - это все равно что гвозди забивать ноутбуком. сам подумай - нужно ВЕДЬ точное совпадение (без учета регистра). Если уж так хочется - НАМНОГО лучше просто создать индекс по текстовому полю - будет быстрее намного.

в) я вернусь к старой теме - fulltext индекс это атавизм. он в дальнейшем ограничит возможность миграции на другую архитектуру таблиц.

г) статье 5 лет. mysql меняется до неузнаваемости каждый год. я сам люблю всё делать по старинке, но fulltext - это здесь не решение.

д) Назови хоть один крупный проект (с большим объемом хранимых текстовых данных), который использует mysql fulltext индексы?

2Stek: при всём уважении, ты, наверно, просто не подумал, перед тем как написать fulltext. Просто слово "индекс" было бы актуальней. Сам подумай - на то он и fulltext, что бы искать в тексте. А тут - просто совпадение строк нужно реализовать.

Цитата:

б) использование fulltext индекса для тегов - это все равно что гвозди забивать ноутбуком. сам подумай - нужно ВЕДЬ точное совпадение (без учета регистра). Если уж так хочется - НАМНОГО лучше просто создать индекс по текстовому полю - будет быстрее намного.

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

В общем все равно в конечном варианте будет все от задачи зависеть. И если скажем проект рассчитывается на ну 1к записей, то писать "по правилам" смысла нет, легче дать одно текстовое поле и вперед, хоть в phpmyadmin'е вбивай, решение за 2 минуты.

Stek писал:

если скажем проект рассчитывается на ну 1к записей, то писать "по правилам" смысла нет, легче дать одно текстовое поле и вперед, хоть в phpmyadmin'е вбивай, решение за 2 минуты.

на 100% согласен.
с этого и начинали - если там будет 1к записей - можно сделать и на коленке.

Может ты или я неправильно поняли слово теги. В моём понимании - речь идёт о тегах аля вордпресс. Кликнул ты на тег - а тут тебе список постов, которые были помечены этими тегами. Кликнут на посте - а внизу список тегов, каждый - как ссылка. там совпадение нужно точное, потому я и писал, что fulltext не нужен. Хватит просто сделать кейворд индексным полем.

Если речь идёт просто о строке, где перечисляются кейворды (типа meta keywords) без ссылок каких-то, то я бы это тегами не называл.

тег это признак.признак характеризующий/объединяющий чего либо
это может быть линком, а может и не быть.

Теги имелись в виду, такие как на тубах, ну или у вордпресса.

Stek: вариант с fulltext это не первый, а третий уже.
Я имел в виду под 1ым - scuttle (собственно, оиз этого скрипта и взял идею), 2ой вариант это toxi

выбирай второй вариант, если будешь развивать проект этот вариант более универсальнее окажется

Вариант уже выбран, но за дискуссией слежу, может что-то интересное ещё скажут.

В первом варианте теги придется матчить либо через fulltext индекс что будет работать, но не фонтан, либо через LIKE '%TAG%' что вообще жопа полная )

Так что второй, конечно. Плюс статсы по тегам считать можно будет.

2-й вариант. Тот же упомянутый тут вордпресс устроен именно так и не только. Использовать достаточно удобно в сравнении с 1-м вариантом, можно вытаскивать данные и 1 запросом, правда более сложным (т.е. с join).
У меня на нескольких проектах этот вариант отлично работает, правда миллионов записей нет, всего несколько тысяч. В общем, 2-й и логичнее и правильнее с точки зрения теории организации реляционной БД (как раз выше упоминали нормализацию).