サブフォーラムに異なる管理者とそれらを担当するモッズがあり、ユーザーが個々のサブフォーラムから禁止される可能性があるウェブサイト用の小さなフォーラムコンポーネントを構築しています。私が持っている禁止テーブルは次のようになります。
_Bantable_
user_id
group_id
start_date
end_date
banned_by
comment
最初は最初の 4 つの列を主キーとして使用するつもりでしたが、同じフォーラムから同じ時間に誰も禁止されないため、1 つ使用しても問題ないかどうか疑問に思っています。それに関係なく、それらがすでに禁止されているかどうか、またどのくらいの間隔で禁止されているかを確認する必要があります. ここではキーを使用せず、user_id と group_id にインデックスを作成し、必要に応じてそれらを検索する必要がありますか?
100% 明確ではありませんでしたが、特定のユーザーごとに一時的な禁止機能が必要なようですgroupId。この場合、複合主キーを作成する必要があります。
user_id,
group_id,
end_date
これにより、次のことが可能になります
SELECT * FROM bantable WHERE user_id=$currentUserToCheck AND group_id=$currentGroupToCheck AND end_date < $currentDate
またはそのようなもの
注:遵守しているデータベース設計原則に関して主キーを一貫したものにしたい場合は、主キーをuser_id(実際には一意の識別子であるため) にしてから、複合インデックスを作成することができます。上記で指定した3つの列。
個々のインデックスを必要とするこのテーブルに対して実行するクエリには、それらのインデックスが正しく生成されていることを絶対に確認してください。
なぜuser_id主キーとして使用しないのですか？つまり、使用する必要すらありませんauto_increment（これは明らかにここでは意味がありません）。
とにかくログイン時にリクエストすることを推測すると、user_idこれはおそらく、問題を禁止するためのエントリさえあるかどうかを調べるための最高のパフォーマンスを提供します。
過去の禁止の歴史的記録が必要ですか?
そうでない場合は、 で複合 PK を作成し{user_id, group_id}ます。現在のデータが何であれ、現在誰が禁止されている_Bantable_かが決まります。禁止が期限切れになったら、対応する行を削除するだけです (そして、必要かどうかを検討してください1 )。end_date
履歴レコードが必要な場合は、以前のように元のテーブルにアクティブな禁止を入れますが、禁止が期限切れになったら、それを削除するだけでなく、代理 PK 2を持つ別の「履歴」テーブルに移動します。 （同じユーザー/グループのペアが複数の行にある可能性があります）および時間の重複を防ぐトリガー（この{user_id, group_id}ようなもの）から独立しています。
1これが禁止が終了する日付である場合、あなたはそれを必要とします. これが禁止が終了した日付である場合、あなたはそうしません - その時までに行はなくなります.
2または、PK on {user_id, group_id, start_date}.