Структура базы данных для 1-многих-многих

Question

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

• Листинг: Отдельный пост с текстом заголовка, датой поста и простой другой информацией.Соединится с таблицей пользователя, чтобы получить имя пользователя.

• Теги: у каждого списка может быть несколько тегов, принадлежащих «типу» Пример:

  Жанр: боевик, сверхъестественное, комедия

  Производители: Sunrise, Bones

• Дополнительные поля: у каждого списка тоже могут быть дополнительные поля Пример:

  Даты выхода: 18 декабря 2010

  Продолжительность: 120 минут

Нормализованный путь будет выглядеть примерно так:

- Listing_table (list_id, user_id, list_title, list_content, list_date)

- Tags_table (tag_id, tag_type, tag_name, tag_slug)

- Tags_Listing_table (list_id, tag_id)

- Field_table (list_id, field_name, field_value)

Будет ли это хорошо?Также, что было бы лучшим способом эффективно запросить всю эту информацию.Я не думаю, что это возможно, чтобы получить все это в одном запросе.какие у меня варианты?

Также каждый листинг будет загружать несколько тем, и внутри этих тем будет несколько сообщений, все на одной странице, вроде:

[SINGLE PAGE]

Список (заголовок, содержимое, теги, дополнительные поля)

• Тема 1
  • Запись 1
  • Запись 2
• Тема 2
  • Сообщение 1
  • Сообщение 2

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

Answer 1

Если вы стремитесь к масштабируемости или производительности, вы почти наверняка пожалеете об этом:

-- Field_table (list_id, field_name, field_value)

По некоторым причинам см. Отражение SQL Antipatterns . Эта структура начинается на слайде 16. Также читайте Плохой CaRMa , что связано как с масштабируемостью, так и с производительностью.

Answer 2

Это похоже на типичный подход entity-attribute-value .Эта модель хороша, особенно для веб-сайтов с высоким трафиком, но она не подходит для SQL.Вместо:

select * from Listing_table where postdate > '2011-02-01'

Вы будете писать запросы вроде:

select  *
from    Listing_table lt 
where   (select value from field_table ft where lt.list_id = ft.list id 
         and field_name = 'postdate') > '2011-02-01'

И это только для простого сравнения дат.Это становится действительно очень быстро.

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