Структура таблиц и логика работы с тегами (теги контента, метки)

[Spear]

Структура таблиц и логика работы с тегами (теги контента, метки)

Здравствуйте,
стулкнулся с такой задачей: делается проект UGC направленности, то есть весь контент - от пользователей.

Получил "под дых" там, где ожидал меньше всего, а именно - в структуре базы данных и логике работы с тегами (матками) контента.

Собирался делать так:

1. Таблица tags_lib - в ней хранятся все теги в единственном экземпляре, и их номера (идентификаторы). Структура - tag_id (int), tag (varchar)
например:
1, PHP
2, Google
3, Microsoft

2. Таблица связи тега с контентом tag_2_content. Структура: object_id (номер "помеченной" новости, например), tag_id (номер тега), rel_type (тип контента, например - новость, компания)
Пример записи в такую таблицу для Новости ХХХХ, номер новости - 123,теги новости - "Google, Microsoft":
object_id, tag_id, rel_type
123 - 2 - news
123 - 3 - news

Все просто и красиво. Но проблема вот в чем - как быть, если кому-то вздумается указать теги не как "Google, Microsoft" а скажем "GOOGLE, MicroSoft". То есть схема эта работать будет, но она сделает так что теги превратятся в "Google, Microsoft", а нужно чтобы теги, введенные пользователями, отображались под контентом именно в таком виде, в котором их указали. Кому-то проще ввести "php", кому-то "PHP".

Пока есть только 1 вариант - в дополнение к приведенной схеме также хранить все теги статьи в дополнительном поле, именно в таком виде в котором их указал пользователь. Это приведет в дублированию данных, но:
1. пользователь будет видеть теги так, как он их ввел
2. для выборки по тегам это поле исопльзоваться не будет, для вбыорки будет использоваться таблица связей - tag_2_content

Подскажите, пожалуйста, как быть? Контента на сайте будет достаточно много (тегов, соответственно, тоже)

 

[Beavis]

Spear
а если правильный collation указать, какая разница?

 

[A1x]

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

 

[mz]

Spear
проще (да и правильнее) оставить вариант регистра, который был добавлен первым. Тем более что тегов будет много (а в одном только php 8 комбинаций)
Проблем с таким решением не вижу

 

[Spear]

Beavis
не понял юмора, если честно )

A1x
то есть раздумать таблицу, по которой идет выборка, бесполезными (для выборки и работы) данными? По-моему глупо.

mz
проще, я согалсен. Но кому-то может очень непонравиться предлженый системой вариант написания. кому-то удобнее mircosoft, какой-то фрик напишет g00gle а самые психически-уровновешанные личности напишут Google. И как быть?

Потому пока что единственный вариант - дублировать указанные пользоваетелем теги (в том виде, в котором он их ввел) в поле varchar, прямо как "tag1, tag2, blabla". Это будет или дополнительная таблица (wicked_tags) или доп. поле.

 

[С.]

С какой целью введена первая таблица с кодами? Почему бы теги не хранить, как есть?

 

[Spear]

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

вторая таблица я уже писал зачем.

Почему бы теги не хранить, как есть?

действительно

 

[clevel]

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

Это типа как первоформы слова и производные. Если не находить для всех слов текста первоформы - то поиск будет без морфологии, то есть ограниченным по эффективности нахождения нужных документов.

 

[A1x]

Автор оригинала: Spear
A1x
то есть раздумать таблицу, по которой идет выборка, бесполезными (для выборки и работы) данными? По-моему глупо.

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

 

[Stalone]

я бы сделал поле tag уникальным, при добавлении insert ignore, наверное. а для красоты ucfirst(strtolower($tag))

 

[LeaetherStrip]

Spear
Показывать юзеру теги в том виде, в кот-ом он их ввел - архиправильная идея.
Смотри. Один раз ты строку по-любому разберешь, так? И ID тегов + "канонические имена" получишь?
Ну и храни в табличке поста (или чего там) в отд. поле сериализованный массив вида

id_тега => тег_как_введен_юзером

или же

канонический_вид => тег_как_введен_юзером

типа

microsoft => MiCRoSoFT
google => gOOgle

при выводе unserialize(), парсишь и выводишь.