問題を解決し、関係を特定する方法を見てみましょう。
ユーザーが承認されているかどうかを確認するコードを作成する場合、編集を実行しているユーザーと編集中のユーザーの 2 つの主要なデータが必要になります。したがって、アプリケーションが尋ねる質問は、「ユーザー A がユーザー B を編集できるか?」ということです。
リレーションシップのセマンティクスを少し無視して、その質問に対する答えをどのように調べるかを考えてみてください。
table can_edit:
requestor_id | edited_id | permission
=====================================
User A | User B | YES
User A | User C | YES
User A | User D | YES
User A | User E | NO
User B | User A | YES
User B | User C | YES
User B | User D | NO
etc...
このルックアップ テーブルを使用して、誰が誰を編集するためのアクセス権を持っているかを判断できます。しかし、この表が何を説明しているかをもう一度見てください。YES/NO の質問に対する答えを探しているので、もっと簡単に表現できます。
table can_edit:
requestor_id | edited_id | permission
=====================================
User A | User B | YES
User A | User C | YES
User A | User D | YES
User B | User A | YES
User B | User C | YES
etc...
NO
ここでは、アクセス許可を削除しました。ここで、 「パーミッション チェックに一致するエントリがあるか?」と尋ねることができます。can_edit
ルックアップを実行して行が存在する場合は、アクセスを許可できます。
現在、permission
列は常に であるためYES
、それを含める意味はあまりありません。これで、基本的にユーザー ID の関係のリストであるテーブルができました。
この時点で、データベース ダイアグラムを使用して関係がどのように見えるかを描くことができます。
users:
user_id <-----+
email | can_edit:
pass_digest +-------- requestor_id
+========== edited_id
users: |
user_id <====+
email
pass_digest
Rails Association guideのサンプル図を見ると、この図が と の両方has_many :through
によく一致していることがわかりますhas_and_belongs_to_many
。これらはどちらも多対多の関係を表しています。
実装の詳細に関する限り、「ユーザー A はユーザー B を編集できますか?」の両方に気付くでしょう。「ユーザー B はユーザー A の友達ですか?」関係に異なる用語を使用しているだけで、基本的に同じ質問です。その知識があれば、Ryan Bates によるこの優れたスクリーンキャストなど、この自己参照has_many :through
関係を定義する方法について多くのことが書かれていることがわかります。