シンプルなデータベーステーブルの設計/レイアウト

Question

仮説の例として、次のシナリオのテーブルをレイアウトする最良の方法は何でしょうか

受講者を追跡するためのアプリを書いているとしましょう。毎年初めに、すべての学生を追加します（手動でこれを行います-ここで、各学生に学生IDを割り当てる必要がありますか？そのテーブルを学生と呼びましょう）。これから、毎日、すべての生徒をテーブル生徒に表示し、ユーザーが出席を選択できるようにします。

では、テーブルをどのようにレイアウトすればよいですか？ （意味がわからない場合は、各列、行に入力するデータを意味します...）たとえば、Student IDを持つ学生テーブルを作成し、各学生に対して毎日新しい行を作成します列1：学生ID、列2：日付、列3：ステータス（出席/不在）の出席テーブル。ただし、それはあまり効率的ではないようです。どう思いますか？

更新：これらの最初のすべての回答から、生徒出席表の各行に1人の生徒がいるように見えます（出席/不在として指定されている場合）行ごとに複数の学生IDを含める必要がありました（ある日に欠席したすべての学生に対して）。それは良くなるのでしょうか、それとも悪くなるのでしょうか（おそらくあいまいです）？実際、この動きが役立っている唯一のアクションはすでに簡単に達成できるため、効率が低下すると考え始めています。うーん...

Answer 1

生徒表

• STUDENT_ID 、pk
• FIRST_NAME
• LAST_NAME

STUDENT_ATTENDANCE テーブル

• STUDENT_ID 、pk、fk
• ABSENT_DATE 、pk

IS_ABSENT 列は必要ありません-日付があるということは、生徒が不在だったことと、その日付の両方を示しています。欠席日は出席した日よりも少ない可能性が高いため、欠席日のみを保存してください。

主キーを2つの列の複合にすることで、重複がないようにします。

  

行ごとに複数の学生IDを含める場合、ある日欠席しているすべての学生の場合はどうなりますか？それは良くなるか悪くなるか

その後、追加のstudent_idを単一の列にコンマ区切りリストとして保存するか、追加のstudent_idごとに追加の列を保存します。各student_idに追加の列が機能することはありません。毎年、新しい学生ごとに列を追加することになります。 student_idsのリストを連結することはより現実的ですが、特定の学生または学生グループについてレポートする場合、詳細を引き出すのは面倒です。文字の制限により、単一の列では存在しない可能性のあるすべてのstudent_idを保存できないというリスクがあります。

提案した STUDENT_ATTENDANCE テーブルの使用をお勧めします。

Answer 2

データベース設計に関する重要な点は、モデルに整合性を提供することです。したがって、あなたの例では、週末、休日、または挿入日に該当する日付の学生の欠席を記録したくないでしょう。そのため、CALENDARテーブルも必要です。 STUDENT_ABSENCEは、STUDENTとCALENDARの間の交差テーブルです。つまり、STUDENTテーブルのIDとCALENDARのDAYの両方に対する外部キーがあります。

これは過剰なエンジニアリングのように思えるかもしれませんが、学校で起こるほとんどすべてのことはスケジューリングを伴うため、カレンダーが不可欠です。可能な限り最適なモデルを構築するために、可能な限りそれを使用することをお勧めします。

また、STUDENT_ABSENCEテーブルに必要な他の属性を検討してください。私の頭の上では、欠席が事前に通知されたかどうか（例：学期中の家族の休日）、欠席が承認されたか、欠席が病気によるものかを記録します。

Answer 3

StudentIDを外部キーとして持つMissedClassesテーブル、日付、コース、場合によっては期間、そして場合によっては免除のための別の列があります。彼らが出席しなかった場合、エントリを配置します。

推論：ほとんどのクラスにほとんどの人が出席することを望んでいるので、ミスを追跡するだけで済みます。

Answer 4

複数の値を組み合わせて値のリストを作成し、それを単一のセルに保存すると、テーブルはCoddによって最初に定義された最初の標準形式ではなくなります。テーブル内にテーブルを保存することにより、Dateによって再定義された最初の標準形式に準拠できます。ほとんどの初心者はそうしません。通常、値のリストをコンマ区切りの文字列にマッシュし、リスト全体を単一のアトミック値であるかのように保存します。

彼らが後で見つけるのは、単純な方法で複雑な操作を表現するために、関係演算子、特に結合の力を利用できないことです。これは通常、「非効率」よりも初心者に費用がかかります。持っているでしょう。テーブル内にテーブルを配置したとしても、データを使用して日常的なことを行うのは、必要以上に難しいことがわかります。

得られた優れた提案のほとんどは、正規化されたスキーマを実現するためにテーブルを分解することです。正規化のルールを破るタイミングとフォローするタイミングを後で学習するまでは、通常、これが従うのに最適なプランです。

これは典型的な12歳向けのものではありません。あなたは典型的な12歳のようには聞こえません。ですから、高校で悪いデータベース設計を学ばせるのではなく、良いデータベース設計の基礎を理解して、それを解いてからもう一度やり直さなければなりません。

Answer 5

学生IDを含む学生テーブルと、名前、成績などの各学生に固有の情報があります。次に、学生ID、日付、ステータス（現在/不在）があるstudent_attendanceテーブルがあります。

これは大量のデータを収集しますが、実際にはそれほど多くのデータではなく、出席に関するいくつかの種類のレポートを非常に簡単に実行できます。

1行に複数の学生IDを配置するのは望ましくありません。行数は少なくなりますが、同じ量のデータがあり、テーブル/レポートのクエリが厄介になるためです。