Моделирование теговых элементов в базе данных - PullRequest
Новая
       29

Моделирование теговых элементов в базе данных

0 голосов
/ 12 сентября 2011

Я сохраняю теги для сообщений как отношения многие ко многим, как в этом сообщении .

Теперь я хочу расширить теги, чтобы иметь возможность помечать объекты, отличные от сообщений,У меня есть все это в таблицах с именами сообщений, ссылок, статей и т. Д. Если я выберу: 

tags_items

tag_id | item_id | item_type
-----------------------------
1        2         post
1        42        link
3        7         article

Или создайте несколько таблиц 

tags_posts
tag_id | post_id 

tags_links
tag_id | link_id 

tags_article
tag_id | article_id

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

Каковы преимущества и недостатки каждого подхода?

Ответы [ 2 ]

1 голос
/ 12 сентября 2011

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

Taggable_Items
    tag_item_id INT (PK)

Posts
    post_id    INT (PK, FK to tag_item_id in Taggable_Items)
    posted_by  INT (FK to your Users table or whatever)
    post_text  VARCHAR(MAX)
    ...

Links
    link_id      INT (PK, FK to tag_item_id in Taggable_Items)
    url          VARCHAR(1000)
    description  VARCHAR(MAX)
    ...

Tags
    tag_id  INT (PK)
    name    VARCHAR(20)

Tagged_Items
    tag_item_id (PK, FK to tag_item_id in Taggable_Items)
    tag_id      (PK, FK to tag_id in Tags)

Надеюсь, это достаточно ясно.Пожалуйста, оставьте комментарий, если он не имеет смысла.

0 голосов
/ 12 сентября 2011

Вы должны сделать свой первый шаг еще дальше. Вместо item_type в качестве varchar или char это должен быть внешний ключ к таблице типов элементов.

...