Рекомендуемая таблица Настроить для ситуации один ко многим / много к одному - PullRequest
0 голосов
/ 28 мая 2009

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

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

  PostID   VisibleTo
 PostingA    user1,user2

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

User   VisiblePosts

user1 posting1, posting2

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

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

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

Ответы [ 3 ]

2 голосов
/ 28 мая 2009

Три стола ...

Пользователь: [Идентификатор пользователя] [OtherField]

Сообщение: [Сообщения дан] [OtherFields]

UserPost: [Идентификатор пользователя] [Сообщения дан]

User.UserId Присоединяется к UserPost.UserId, Post.PostId присоединяется к UserPost.PostId

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

1 голос
/ 28 мая 2009

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

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

0 голосов
/ 28 мая 2009

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

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

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

  • PostingVisibilityTable с PostingID и UserID

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

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

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

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