コメントでは、基本的に、確立された友情(要求ではなく)はセットアップで常に対称的であると述べています。その場合、基本的に2つのオプションがあります。2つの行に格納するか、いずれかの列に一致させて選択することができます。前者はより単純なクエリを生成しますが、後者は対称性がデータベース構造に固有であることを保証し、重複データの保存も回避します。だから私は後者、つまり何らかの形のを選びWHERE (User1 = XX or User2 = XX )
ます。クエリは、1つの列だけのクエリが同じ行数を使用する場合の2倍の時間がかかる可能性がありますが、行数は他のストレージスキームの半分にすぎないため、パフォーマンスの面での正味の影響は無視できるはずです。 。
リクエスト用に個別のテーブルが必要か、確立された友情が必要かは、関連データとアプリケーションの制御フローの両方の点で、これら2つがどれほど類似しているかによって異なります。したがって、たとえば、確立された友情と保留中のリクエストの両方を、おそらく異なる色などで、同じリストに表示する単一のリストをユーザーに提示する場合、データベースに単一のテーブルを含めると、より多くのことができます。適切です。一方、リクエストと友情を別々に扱うことがほとんどの場合、2つのテーブルを持つ方が自然になります。share_calendar
また、ある時点で、フレンドシップには次のような属性が必要であるのに対し、リクエストには次のような属性が必要であると判断したconfirmation_key
場合は、別のテーブルを使用したほうがよいでしょう。
status
これを単一のテーブルにすることにした場合は、列と値requested
とを呼び出すなど、列挙型のより記述的な値をお勧めしますestablished
。私は、一見すると、の値をrequest = 1
「これは要求のみであり、確立された友情ではない」と解釈します。これは、あなたが関連付ける意味とは正反対です。このあいまいさは、さまざまな人がコードを維持する必要があるときにエラーにつながる可能性があります。そして、数年後には、あなた自身でさえあなたの古いコードを誤解するかもしれないので、あなたは今のあなたとは別の人で十分になるでしょう。ですから、そこで説明してください。
もう1つの注意:データベースがクエリに表示される方法を微調整するために、いつでもビューを使用できます。たとえば、ビューを作成できます
CREATE VIEW SymmetricEstablishedFriends AS
SELECT User1 AS Me, User2 AS Friend, Time
FROM Friends
WHERE Status = 'established'
UNION
SELECT User2 AS Me, User1 AS Friend, Time
FROM Friends
WHERE Status = 'established'
これにより、データは確立された友情のみに制限され、対称化が行われます。クエリでこのようなビューを使用すると、すべてのクエリでテーブル構造のすべての詳細を処理する必要がなくなります。そして、これらの詳細を変更した場合、変更する場所が少なくなります。