文字列の代わりに外部キーを使用してIDのリストを格納する場合、どちらのデザインが優れているか
オンライン試験システムを構築しています。テーブル、QuestionおよびGeneralExamを設計しました。テーブルGeneralExamには、名前、説明、期間などの試験に関する情報が含まれています...
次に、テーブルGeneralQuestionを設計します。これには、一般的な試験に属する質問のIDが含まれます。
現在、私はGeneralQuestionテーブルを設計するために2つのアイデアを持っています：
- これには、general_exam_id、question_idの2つの列があります。
- 2つの列があります。general_exam_id、
list_question_ids（文字列/テキスト）。
どのデザインが優れているか、または各デザインの長所と短所を知りたいのですが。
Postgresqlデータベースを使用しています。
最初のデザインはより良いものです。
これは、質問への外部キーも作成できるためです。また、IDのリストを解析する処理はありません。また、この場合、一般的な試験クエリと一緒にすべての質問を取得することができます（データベースへの1回の往復のみ）。
2番目の設計の場合、一般的な試験のデータベースエントリを取得し、テキストを解析してから、データベースに再度クエリを実行して質問をする必要があります...
- 素敵でトリッキーな質問
使い方次第です。しかし、ほとんどの場合、INTキーが優先されます。通常、主キーを示すIDなどが表示されます。
最終的には使用方法によって異なります。どのような要件が必要になるか。したがって決定します。ただし、INTが最も推奨されます。ここで私は両方を説明しました
int IDの場合（最初のオプション）＃
IDフィールドは、文字列ベースではなく、数値でなければなりません。
- スペースの節約（intは4バイトです。文字列は何バイトでもかまいません。そのため、intは常にパフォーマンスが向上します）
- パフォーマンス上の理由（文字列のキーの一致は整数の一致よりも遅い）
- データの冗長性はint列によって解決されます。外部キーは、データが更新されるたびに更新（または削除）する必要があるため。
- 外部キーの更新/削除はカスケードに設定できます。
文字列/テキストの場合（2番目のオプション）＃
- 外部キーを使用すると、ユーザーが読み取り可能なデータ（つまり、テキスト）を取得するには、JOINを作成する必要があります。説明的な外部キーを使用すると、ユーザーが読み取り可能なデータを取得するためにJOINを作成する必要はありません。これには、SELECTによる読み取りと、データの挿入または変更時の読み取りが含まれます。たとえば、AddressNumに挿入するにはgroupIdが必要です。
- データベース内の人間が読めるデータ。これにより、DBAはSHOW CREATE TABLEを使用して外部キー参照を検索し、1つのテーブルからデータのサンプルを取得してシナリオを理解できるため、JOINしなくても、データの問題をデバッグしやすくなります。
@ user1598390のコメントが好き
OPは、int IDとString IDのどちらを使用するかを尋ねていません。彼/彼女は、int ID（1対多）を使用するか、すべての質問IDを「123311; 121322; 123455; 123487」のようなテキスト列に連結するかどうかを尋ねています。
最初のオプションは整数IDとして、2番目のオプションはテキスト/文字列として受け取りました。
使い方次第です。どのような要件が必要になるか。したがって決定します。ほとんどの場合、最初のオプションが推奨されます。この場合、最初のオプションでは、IDのリストを解析するための追加の処理はありません。