質問

誰かが私のタイトルを編集して、私が意味することをよりよく説明できることを願っています。ただし、このセットアップを検討してください。「解雇」をクリックするまで、ユーザーにメッセージが表示される通知システムを作成したいと思います。次に、このユーザーが通知を却下したことを「覚えておく」必要があるので、再び彼に見せません。これが私の現在の解決策です

  • users テーブルには uid 主キーとユーザー情報
  • notifications テーブルには nid 主キーと通知テキスト
  • notifications_seen 2つの列のあるテーブル、 uidnid

誰かが通知で却下をクリックすると、私は彼らを保存します uid 通知 nidnotifications_seen. 。これは正常に機能しているようですが、phpmyAdminには巨大な赤いメッセージがあります。 notifications_seen インデックスがありません。ただし、どちらの列も一意ではありません。私は本当に完全に役に立たない列を本当に持っている必要がありますか notifications_seen そして、それを主キーと呼びますか?これを行うためのより良い方法はありますか?

役に立ちましたか?

解決

複数の列を使用して、主キーを作成できます。この場合、NIDとUIDを通知_Seenテーブルの主キーとして設定する必要があります。ここでのアイデアは、NIDもUIDも通知_Seenテーブル内で一意にはならないということです。 NID/UIDペアは一意です。これらの2つの列に主要なキーの制約を追加する必要があります。これは通常、この種の状況でやりたいことです。

プライマリキーを簡素化するために自動インクリメントの行を実際に作成したい場合があります。たとえば、最高の候補キーが多くの列で構成されている場合(私はこれを空中から引き出していますが、4つ以上の列を使用してください)、または文字列を含む列があります。ルックアップを行うときに一致するのが遅くなります。しかし、この状況では、2つの列に主要なキーの制約を追加するだけでは問題ありません。

プライマリキーはデフォルトでインデックス付けされます。そのため、2つの列に主要なキーの制約を追加するだけです。これにより、同じUID/NIDペアで誤って行を挿入しないようにすることにより、データの整合性が維持されます。

また、UIDに外部キーの制約をユーザーテーブルのIDに追加し、通知テーブルのIDのNIDに外部キーの制約を追加する必要があります。外部キーの制約を追加すると、実際には通知_Seenテーブルに存在しないUIDやNIDを挿入しないようにします。

他のヒント

複合プライマリキーを作成できる場合があります(両方で構成される uidnid).

インデックスをオンにすることができます notifications_seen それが含まれています 両方 列!または、プライマリキーのためだけに別の列を作成するか、両方を実行します - インデックスがあります uidnid そうかもしれない クエリをスピードアップします(ただし、大きなパフォーマンスの問題に気付くまで、それについてあまり心配しないでください - 将来のためにそれを覚えておいてください)。これらのn:n関係の主要なキーを持つことはひどいものではありません。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top