私が目にする多くのテーブル デザインには、主キーとして id 列があります。たとえば、Logging テーブルの log_id、イベント テーブルの event_id などです。この列は、他のテーブルの他の列に依存せず、レコードを一意に識別します。ルックアップの観点から見ると、情報のルックアップに使用される列は、テーブル内の他の列でもあり、インデックスを作成することもできます (status/event_type/etc など)。では、テーブル内のレコードを表すような id 列を持つ必要があるのは何でしょうか? そのような id 列をログ テーブルから削除し、代わりに複合キーを使用する場合、どのような犯罪を犯していますか? アプリケーションでその列が使用されていない場合に、テーブルにそのような一意の id 列を持つことが一般的に行われているのはなぜですか? 専門家の意見を聞くことを望んでいます。:o
更新: 迅速な返信ありがとうございます。主に、監査テーブルなどのテーブルで複合キーの代わりに代理キーを使用することが非常に一般的である理由を理解したいと思います (他の例もありますが、会話に焦点を合わせようとしています)。このようなテーブルでは、イベント、ユーザー ID、およびタイムスタンプの組み合わせによって一意のレコードを簡単に識別できました。私がオンラインで調査した設計のほとんどは、event_id などのキーを利用しています。本当の理由がある場合、その理由を理解しようとしていますか? 実際、それは db の不要なストレージを消費することを意味するのではないでしょうか?