Проблема с пониманием проектирования бд, поможете?

Question

[samorez999]

Есть у меня большая таблица, назовем ее "объявления". Нужно одному "объявлению" назначить несколько "тегов".

Вот мой ход мыслей:
Создать отдельную таблицу "теги" и перечислить первичные ключи в колонке "теги" первой таблицы. Но перечисление нарушает 1NF.
Создать таблицу типа многие-ко-многим "объявления-теги", но там будет плодиться очень много значений после каждой вставки "объявления".
Можно перечислять теги просто строкой в поле.

Как это делается в реальных проектах?

Comments

[FanatPHP]

Создать таблицу типа многие-ко-многим "объявления-теги".
Фраза "но там будет плодиться очень много значений после каждой вставки "объявления"!!!!!1111". Звучит примерно как "мне надо ходить пешком. Но ведь для этого придется очень много раз переставлять ноги!"

База данных и придумана для того, чтобы в ней "плодились значения".
А с детскими страхами - это к доктору

[samorez999]

FanatPHP, к примеру, у одного объявления в среднем 3 тега, на 1 миллион объявлений будет 3 миллиона записей в "объявления-теги", как там будет по скорости при выборке? Сильно я выиграю, если нарушу правило и буду писать теги, перечисляя их в строку через запятую?

[FanatPHP]

Сильно. Только не выиграете, а облажаетесь.
Если не только писать вопросы, но иногда и читать ответы, то здесь можно увидеть целые стада страдальцев, которые сначала пришли к этому "гениальному" решению, а теперь ходят и канючат "а как мене искать нужныи теги, а как мине удалить адин тег, а почиму у меня база встаёт колом на простом запросе?"

[vgodoo]

samorez999, не помню как там по формам нормализации, но, примерно, кажется, так:
obyav:
id | name | text

tag:
id | name

rightWay:
obyav_id | tag_id

через запятую по-дурацки

[samorez999]

FanatPHP, воу, не предусмотрел этого. А как интересно может встать база на простом запросе? Типа "мине нада переименовать адин тег, пойду переименую во всех записях сразу", да?

[samorez999]

vgodoo, сенки, я так и думал

[FanatPHP]

Очень просто может встать.
Чтобы найти все объявления по тегу надо будет не просто взять из таблицы многие-ко многим только нужные, а тупо перебирать ВСЕ объявления подряд, и в каждом парсить гениальную строку и искать в ней нужный тег. Причем так чтобы вместо него не влез похожий.

А 1NF придумали тупые зануды, которым просто делать было нечего.

[galaxy]

samorez999,

А как интересно может встать база на простом запросе?

напишите запрос на удаление тега, чтобы он использовал индекс, с вашим подходом "через запятую"

Answer 1

[Василий Банников]

к примеру, у одного объявления в среднем 3 тега, на 1 миллион объявлений будет 3 миллиона записей в "объявления-теги", как там будет по скорости при выборке? Сильно я выиграю, если нарушу правило и буду писать теги, перечисляя их в строку через запятую?

1. Представим, что промежуточная таблица объявление-тег - это два гуида.
Тогда одна строчка будет занимать около 32 байт. 3*32*1000000 = 96 мегабайт (метрических)
2. Естественно, выборка будет медленной, если не добавить индекс. Индекс по id объявления ещё примерно столько же займёт. Выборка уже будет быстрее. Для фильтров ещё надо будет добавить индекс в обратную сторону - от id тега.
3. Ещё и фильтроваться по тегам можно будет, что, мне кажется, является одним из важнейших качеств тегов.
4. Если 96 мегабайт тебя пугает - используй int64 или int32 - тогда будет меньше в 2 или в 4 раза соответственно

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

Как уже сказали в комментах - очень сильно обосрёшься.
Выборка, конечно, будет очень быстрая, но
1. Представим что тег - это 6 букв на русском языке, а храним мы строки в Utf8 кодировке.
Тогда на каждое объявление будет тратиться 6*2*3+3+4=45 байт. Соответственно на миллион объявлений уйдёт 45 метрических мегабайт.
2. Но тут не будет индексов, по тому и фильтроваться будет очень дорого

PS: все прикидки по памяти взяты с потолка. В реальной БД числа будут другие, но примерно похожие.
PPS: если не совсем понятно, что я предлагаю, то вот:

._________.             .______________.           .____________.
| post    |             | post_tag     |           | tag        |
|=========|             |==============|           |============|
| id: int |<------------| post_id: int |           | id: int    |
| ...     |             | tag_id: int  |---------->| name: text |
|_________|             |______________|           |____________|

Comments

[samorez999]

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

Answer 2

[Eugene TI]

> Создать таблицу типа многие-ко-многим "объявления-теги", но там будет плодиться очень много значений после каждой вставки "объявления"

Что значит "много"? Столько, сколько тегов у объявления. Ни больше, ни меньше.
По 2…16 байт на один тег для одного объявления, как выше написали.
Меньше только если не использовать теги.
И объявления.

Answer 3

[Drno]

я вообще не эксперт по БД, но может создать отдельную таблицу для тегов... перечислить их там
далее добавить поле\поля к объявлению и там уже помечать. типо 1 есть тег, 0 нет тега... и так по каждому

Comments

[FanatPHP]

Ну если вы не эксперт, то зачем лезть с ответом?

[Drno]

FanatPHP, потому что захотелось

Answer 4

[Константин Цветков]

Использование для тегов отдельной таблицы — правильное решение.
Но не всё так однозначно. Использование списка тоже возможно и имеет свои преимущества. Например, на хабре используется отдельная таблица и нет возможности добавить свой уточняющий тег для вопроса. На других web2 можно добавить в список свой. По поводу страха перед удалением и переименованием: на хабре когда-нибудь удаляли тег? А как давно переименовывали?
Использование списков поддерживает множество СУБД, а некоторые имею специальный тип данных.

Comments

[FanatPHP]

Например, на хабре используется отдельная таблица и нет возможности добавить свой уточняющий тег для вопроса.

В огороде бузина, а в Киеве дядька.

КАКАЯ связь между отдельной таблицей и возможностью/невозможностью добавления?

Возможности добавить свой тег нет не потому что "таблица отдельная", а потому что такие вот альтернативно одарённые личности тут же засрут теги отходами своей жизнедеятельности.