Когда включать связанные поля в таблицу БД, а когда нет?

Question

У меня есть таблица «сообщений», и я хочу отслеживать оценки для каждого сообщения. Обычно я бы добавил поле рейтинга со значениями int в той же таблице, которая ссылается на другую таблицу «рейтинг», которая содержит фактические данные рейтинга. Что-то не так с удалением этого поля рейтинга и вызовом оценок непосредственно из таблицы рейтингов на основе postID? Таблица сообщений не имеет прямой ссылки на рейтинг, но таблица рейтинга ссылается на идентификатор сообщения. Какой способ лучше / правильный. ТИА

Answer 1

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

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

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

Но я бы не сказал, что ваше дело относится ни к одной категории; так что просто держите его в таблице сообщений.

---

Я собираюсь обобщить некоторые распространенные ситуации.

Posts
========
PostId           Ratings
Text             ==========
RatingId  ====>  RatingId
                 RatingName

Используйте это, если у вас есть набор возможных значений рейтинга, таких как «Хороший», «Средний» и «Плохой», и все сообщения имеют эти значения. RatingValue будет строкой, идентифицируемой идентификатором.

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

Posts
===========
PostId
Text
RatingValue

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

Posts            PostRatings
========         ===========        Ratings
PostId    <====  PostId             ===========
Text             RatingId     ===>  RatingId 
                                    RatingName

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

                 PostRatings
Posts            ==============
========         [PostRatingId]
PostId    <====  PostId
Text             RatingValue

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

Posts            PostRatings
========         ===========        User
PostId    <====  PostId             ===========
Text             UserId       ===>  UserId 
                 RatingValue        Name

Answer 2

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

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