0

誰かがポジションの募集を投稿するスクリプトを作成する必要があり、資格のある人は誰でも募集を見ることができますが、そうでない (またはオプトアウトした) 人は募集を見られません。したがって、2 人のユーザーが同じページにアクセスして、異なるコンテンツを表示する可能性があります。そのデータを MySQL DB/テーブルに配置する最善の方法がわかりません。

たとえば、投稿ごとに配置することもできますが、それは次のようになります。

  PostID   VisibleTo
 PostingA    user1,user2

そして、それは間違っているようです (列の CSV スタイル)。または、私は一人で行くことができます：

User   VisiblePosts

ユーザー1 投稿1、投稿2

しかし、それは同じ問題です。ユーザーのユニーク、投稿をユニークにして、一致したところだけ参加させる方法はありますか?

決定は、最初に別のテーブル セットに対して一連のクエリを実行することによって行われますが、それが実行されると、ユーザーが位置を投稿した後に変更されないコードの一部を何度も実行するのは効率が悪いようです。

...再考すると、変更される可能性がありますが、変更されないと仮定した場合 (可能性は低く、ユーザーが資格を失ったものを見た場合の影響はほとんどないため)、これに対する標準的な解決策はありますか?シナリオ？

4

3 に答える 3

2

3つのテーブル...

ユーザー: [UserId] [OtherField]

投稿: [PostId] [OtherFields]

UserPost: [UserId] [PostId]

User.UserId は UserPost.UserId に結合し、Post.PostId は UserPost.PostId に結合します

次に、テーブル UserPost を検索し、表示する投稿を選択するときに Post に参加します

于 2009-05-28T00:14:04.517 に答える
1

これは、多対多の関係または n:m の関係です。

PostVisibilityたとえば、列PostIDとを含む追加のテーブルを作成しますUserID。と の組み合わせが表PostIDにUserIDある場合、その投稿はそのユーザーに表示されます。

于 2009-05-28T00:14:51.847 に答える
0

編集: 申し訳ありませんが、多対多である Posting-User 用語で話していると思います。私はこれを投稿の観点から考えていました-「閲覧権」の用語、つまり1対多です。

何かが欠けていない限り、これは 1 対多の状況であり、2 つのテーブルが必要です。たとえば、各投稿にはそれを閲覧できる n 人のユーザーがいます。投稿は個々のユーザーに固有のものであるため、逆にする必要はありません。

  • PostingID (およびその他のデータ) を含む PostingTable

  • PostingID と UserID を含む PostingVisibilityTable

  • UserID とユーザー データを含む UserTable

表示権限とは別に投稿を作成し、表示テーブルに対して PostingID/UserID のペアを個別に追加/削除します。

現在のユーザーに表示されるすべての投稿を選択するには:

SELECT * FROM PostingTable A INNER JOIN PostingVisibilityTable B ON A.PostingID = B.PostingID WHERE B.UserID = "currentUserID"
于 2009-05-28T00:14:48.570 に答える