Recomendado Ajuste a tabela acima para um para muitos / muitos para um situação

Question

Eu preciso criar um script onde alguém vai postar uma abertura para uma posição, e quem é elegível verá a abertura, mas quem não é (ou opta fora) não vai ver a abertura. Assim, duas pessoas poderiam ir para a mesma página e ver conteúdo diferente, alguns potencialmente o mesmo, alguns totalmente original. Eu não tenho certeza que a melhor maneira de organizar os dados em um banco de dados MySQL / table.

Por exemplo, eu poderia tê-lo organizado pela postagem, mas que ficaria algo como:

  PostID   VisibleTo
 PostingA    user1,user2

E isso parece errado (o estilo CSV na coluna). Ou eu poderia ir com por pessoa:

User   VisiblePosts

user1 posting1, posting2

Mas é o mesmo problema. Existe uma maneira de fazer o usuário única, a postagem única, e tê-los juntar-se apenas quando eles combinam?

A decisão é feita inicialmente fazendo uma série de consultas para outro conjunto de tabelas, mas uma vez que é executado, parece ineficiente ter que alguns pedaço de código executado novamente e novamente quando ele não vai mudar após o usuário envia a posição.

... Pensando bem, isso pode mudar, mas se assumirmos isso não acontecer (como é improvável, e como pouca importância se um usuário vê algo que já não são elegíveis para), existe um padrão solução para este cenário?

Answer 1

Esta é uma relação ou n n para n:. Relação m

Você iria criar uma tabela adicional, dizem PostVisibility, com um PostID coluna e UserID. Se uma combinação de PostID e UserID está presente na tabela, esse post é visível para o usuário.

Answer 2

tabelas Três ...

Usuário: [ID do usuário] [OtherField]

Post: [PostId] [OtherFields]

UserPost: [ID do usuário] [PostId]

User.UserId junta-se a UserPost.UserId, Post.PostId junta-se a UserPost.PostId

Em seguida, procure o UserPost mesa, juntando-se aos Correios quando você está selecionando quais mensagens para mostrar

Answer 3

Edit: Desculpe, eu acho que você está falando em termos Posting pelo usuário, que é de muitos para muitos. Eu estava pensando em isso em termos de posting- "visualização direitos" termos, o que é um-para-muitos.

A menos que eu estou faltando alguma coisa, esta é uma situação um-para-muitos, que requer duas tabelas. Por exemplo, cada postagem tem n utilizadores que podem ver isso. Postagens são exclusivas para um usuário individual, para que você não precisa fazer o inverso.

• PostingTable com postagem (e outros dados)

• PostingVisibilityTable com postagem e UserID

• UserTable com UserID e dados do usuário

Criar as postagens independentemente dos seus direitos de visibilidade, e, em seguida, adicionar / remover postagem / UserID pares contra a mesa de Visibilidade separadamente.

Para selecionar todos os lançamentos visíveis para o usuário atual:

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