Реализация структуры типа массива в базе данных MySQL

Question

В настоящее время я пытаюсь реализовать таблицу в моей базе данных SQL. Я пытаюсь создать таблицу, которую можно использовать для проверки того, понравился ли пользователь на моем сайте публикацию. Идея состоит в том, чтобы иметь таблицу с одной осью, повторяющей публикации на веб-сайте, и одной осью с повторяемыми значениями userID. Затем в каждом поле укажите двоичное значение того, понравилось ли оно им. Мне просто интересно, как бы я это реализовал. Я делал это в C#, создавая классы и преобразовывая их в код на стороне сервера, используя Entity Framework 6.4.0. Любая помощь будет отличной.

Answer 1

Будет ли у каждого пользователя мнение по каждому посту? Если нет, то у вас нет данных, которые вы описали. Если пользователи и сообщения не связаны один к одному, то у вас есть простое отношение. Для каждого сообщения, которое пользователь любит (или не любит?), Есть запись для этого пользователя:

Нравится / не нравится Таблица: Идентификатор пользователя Идентификатор сообщения Двоичное значение, которое указывает, нравится или не нравится

Если в таблице указаны только «лайки», тогда вам не нужен последний столбец.

Такой дизайн будет работать, даже если в этой таблице есть каждый пользователь и каждый пост. Стол может стать большим в спешке и продолжать расти каждый раз, когда вы вводите новый пост. Но если эта таблица включает только фактические «лайки» (и / или «антипатии»), она должна быть управляемой.

Для класса у вас просто есть перечислимое, у которого есть посты «понравились» (и, возможно, другой, который указывает на то, что посты «не понравились»).

Подумайте, что вы пытаетесь изобразить. Задайте себе вопросы. Не просто ухватиться за идею и попытаться «сделать» ее.

Будет ли каждый пользователь иметь мнение о каждом сообщении? Вам нужно хранить «лайки» и «антипатии»? Может ли быть «нейтральное» мнение о посте? Могут ли пользователи изменить свое мнение?

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

Answer 2

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

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

Скажем, таблица user_like_posts со следующими столбцами:

user_id -- foreign key to the "users" table
post_id -- foreign key to the "posts" table

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