Який найефективніший спосіб зберігання тегів у базі даних?

Я впроваджую на своєму веб-сайті систему тегів, подібну до однієї стаціонарної передачі, моє питання - який найефективніший спосіб зберігати теги, щоб їх можна було шукати та фільтрувати?

Моя ідея така:

Table: Items
Columns: Item_ID, Title, Content

Table: Tags
Columns: Title, Item_ID

Це занадто повільно? Чи є кращий спосіб?

На одному елементі буде багато тегів. І один тег буде належати багатьом предметам. Це означає для мене, що вам цілком можливо знадобиться посередницька таблиця, щоб подолати перешкоду «багато-багато».

Щось на зразок:

Таблиця:
Стовпці елементів : Item_ID, Item_Title, Content

Таблиця:
Стовпці тегів: Tag_ID, Tag_Title

Таблиця:
Стовпці елементів_теги: Item_ID, Tag_ID

Можливо, ваш веб-додаток шалено популярний і потребує денормалізації в дорозі, але безглуздо забруднювати води занадто рано.

Ви повинні прочитати повідомлення в блозі Філіпа Келера про тегування схем бази даних. Він намагається зробити кілька і повідомляє про свої результати, як з точки зору простоти побудови загальних запитів , так і з точки зору продуктивності . Кількість тегів, кількість тегів та кількість тегів на предмет - усі фактори. Повідомлення від 2005 року; З тих пір я не знаю жодних оновлень.

Насправді я вважаю, що денормалізація таблиці тегів може бути кращим способом вперед, залежно від масштабу.

Таким чином, таблиця тегів просто має tagid, itemid, name tag.

Ви отримаєте повторювані імена тегів, але це робить додавання / видалення / редагування тегів для конкретних елементів МНОГО простішими. Вам не доведеться створювати новий тег, видаляти виділення старого та переділяти новий, ви просто відредагуйте ім'я тегу.

Для відображення списку тегів ви просто використовуєте DISTINCT або GROUP BY, і звичайно ви можете порахувати, скільки разів тег також легко використовується.

Якщо ви не заперечуєте проти використання нестандартних матеріалів, у Postgres версії 9.4 і новіших є можливість зберігати запис типу текстового масиву JSON.

Вашою схемою буде:

Table: Items
Columns: Item_ID:int, Title:text, Content:text

Table: Tags
Columns: Item_ID:int, Tag_Title:text[]

Для отримання додаткової інформації дивіться цей чудовий пост Джоша Беркуса: http://www.databasesoup.com/2015/01/tag-all-things.html

Існує більше різноманітних варіантів порівняно ретельно для продуктивності, а запропонований вище найкращий в цілому.

Я б запропонував використовувати третю таблицю посередника для зберігання асоціацій тегів <=>, оскільки ми маємо багато-багато відношень між тегами та елементами, тобто один елемент може бути пов'язаний з декількома тегами, а один тег може бути пов'язаний з декількома елементами. HTH, Valve.

Ви не можете реально говорити про повільність на основі даних, наданих у запитанні. І я не думаю, що на цій стадії розробки ви навіть не повинні занадто сильно турбуватися про продуктивність. Це називається передчасної оптимізацією .

Однак я б запропонував вам включити стовпчик Tag_ID у таблицю Теги. Зазвичай є хорошою практикою, щоб кожна таблиця мала стовпчик ідентифікатора.

Якщо простір буде проблемою, майте теги 3-ї таблиці (Tag_Id, Назва), щоб зберігати текст для тегу, а потім змініть таблицю тегів на (Tag_Id, Item_Id). Ці два значення також повинні забезпечувати унікальний складений первинний ключ.

У елементах повинно бути поле "ідентифікатор", а в тегах має бути поле "ідентифікатор" (первинний ключ, кластер).

Потім складіть проміжну таблицю ItemID / TagID і покладіть туди " Ідеальний індекс ".