Рекомендуемая таблица для ситуаций «один ко многим» или «многие к одному».

Question

Мне нужно создать сценарий, в котором кто-то опубликует вакансию, и любой, кто имеет на это право, увидит вакансию, но тот, кто этого не сделает (или откажется), не увидит вакансию.Таким образом, два человека могут зайти на одну и ту же страницу и увидеть разный контент, потенциально одинаковый или совершенно уникальный.Я не уверен, что это лучший способ расположить эти данные в базе данных/таблице MySQL.

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

  PostID   VisibleTo
 PostingA    user1,user2

И это кажется неправильным (стиль CSV в столбце).Или я мог бы пойти с человеком:

User   VisiblePosts

пользователь1 сообщение1, сообщение2

Но это та же проблема.Есть ли способ сделать пользователя уникальным, уникальное сообщение и позволить им присоединяться только там, где они совпадают?

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

... Если подумать, это МОЖЕТ измениться, но если мы предположим, что это не так (поскольку это маловероятно и с небольшими последствиями, если пользователь видит что-то, на что он больше не имеет права), существует ли стандартное решение для этого сценарий?

Answer 1

Это отношение «многие ко многим» или отношение n:m.

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

Answer 2

Три стола...

Пользователь:UserId] [Другое поле

Почта:Postid] [Другие поля

Пользовательское сообщение:UserId] [postid

User.userid соединяется с userpost.userid, post.postid соединяется с userpost.postid

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

Answer 3

Редактировать:Извините, я думаю, вы говорите в терминах Posting-User, то есть многие-ко-многим.Я думал об этом с точки зрения «прав на просмотр», то есть «один ко многим».

Если я ничего не упустил, это ситуация «один ко многим», для которой требуются две таблицы.Например, каждое сообщение имеет n пользователей, которые могут его просмотреть.Публикации уникальны для отдельного пользователя, поэтому вам не нужно делать обратное.

• PostingTable с PostingID (и другими данными)

• PostingVisibilityTable с PostingID и UserID

• UserTable с UserID и пользовательскими данными

Создавайте публикации независимо от их прав на видимость, а затем отдельно добавляйте/удаляйте пары PostingID/UserID в таблице видимости.

Чтобы выбрать все публикации, видимые текущему пользователю:

SELECT * FROM PostingTable A INNER JOIN PostingVisibilityTable B ON A.PostingID = B.PostingID WHERE B.UserID = "currentUserID"