Какова правильная стратегия нормализации базы данных со статьями и тегами для статей? - PullRequest
0 голосов
/ 08 июля 2010

Я строю систему, которая хранит статьи и теги, которые классифицируют статью.Стандартные вещи, похожие на то, как это делает этот сайт.Теперь мой вопрос заключается в том, должен ли я хранить теги в отдельной таблице, которая содержит только теги и идентификаторы статей, или хранить теги в дополнительном столбце таблицы статей.Моим первым инстинктом было бы нормализовать базу данных и иметь две таблицы.Проблема заключается в том, что интерфейс, с которым пользователь управляет тегами, представляет собой простое текстовое поле со всеми тегами, разделенными запятыми.Поэтому, когда пользователь фиксирует свои изменения, чтобы узнать, какие теги были добавлены, изменены или вычтены, мне нужно будет сначала выполнить запрос к базе данных, сравнить результаты с новыми данными на основе тегов, а затем обработать изменения соответствующим образом.Процесс с огромными накладными расходами по сравнению с простым обновлением файла, указанного в одной строке таблицы статей.Как бы вы это сделали или есть третий вариант, который я не рассматривал?

ПД.Я застрял с реляционной базой данных для этого проекта.

Ответы [ 2 ]

1 голос
/ 08 июля 2010

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

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

0 голосов
/ 08 июля 2010

Вам необходимо нормализовать базу данных, чтобы выполнить запросы, такие как «найти все статьи с тегом T».

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

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

Если вы используете SQL Server 2008, тогда я предлагаю вам взглянуть на команду MERGE.

...