2009-05-28 5 views
0

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

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

PostID VisibleTo 
PostingA user1,user2 

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

User VisiblePosts 

user1 posting1, posting2

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

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

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

ответ

1

Это отношения или н многие-ко-многим: м отношения.

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

+0

Итак, в этом случае, если у пользователя было 3 сообщения, которые были видимыми, и каждый из этих сообщений был видимым для 2 пользователей, столбец userID должен был бы указать этого пользователя 3 раза, а его три сообщения появятся в столбце postID 6 раз? Или я пропустил часть концепции? – Anthony

+0

@ Энтони, Правильно. Вы также должны сделать PostID/UserID UNIQUE, потому что пользователь не может иметь доступ к тому же сообщению «дважды». – molf

2

Три таблицы ...

Пользователь: [UserId] [OtherField]

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

UserPost: [UserId] [сообщения дан ]

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

Тогда посмотрите таблицу UserPost, присоединение к сообщение, когда вы выбираете, какие должности, чтобы показать

0

Edit: К сожалению, я думаю, что вы говорите с точки зрения проводок-пользователей, что многие-ко-многим. Я думал об этом с точки зрения публикации - терминов «просмотр прав», которые являются «один ко многим».

Если мне что-то не хватает, это ситуация «один ко многим», которая требует двух таблиц. Например, в каждой публикации есть 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" 
Смежные вопросы