学校データベーススキーマ
Oct 22 2020
私は学生の登録とスケジュールを処理する簡単な学校システムに取り組んでいます。さらに、システムは、幼稚園、初等、中等、高等学校（幼稚園とk12）などのさまざまなタイプの学校を処理する必要があります。
私はDB設計の専門家ではありませんが、読んだり練習したりして学んだことから、できることを続けています。
- 学生
- 親
- Student_parent（複数の親がシステムに参加したい場合）
- 学校（システムが生徒がどのレベルに属しているかを確認できる場所（プライマリまたはセカンダリなど））
- 科目（学校のすべての科目）
- クラス（基本的にスケジュール-時間割）
- 教室（学校内のすべての部屋と実験室（基本的に学校の施設））
- 出席（まだ）
- マーク（まだ）
テーブルの関係は十分ですか、それとも再設計する必要がありますか？この基本スキーマに問題はありますか？システムにとって十分ですか？学期（学期1と学期2）と年を実装する方法は？年末はどうですか。学生を新年に移す方法（これを実装する方法）？
プログラミングを開始する前に、スキーマの改善や問題についていくつかのポイントを取得したいと思います。
ありがとうございました
。。編集：ジョンハーバートの提案を実装します。。。
学校には学部がなく、生徒の数がその年に本当に主観的であるため、最後の1つを除いてジョンポイントを実装します。
- テーブル名をプレフィックス付きでグループ化するように変更しました。
- より良い検索とグループ化のためにジョンによって提案されたようにいくつかのフィールドを変更しました
- 表の用語を追加し、それを学校に接続しました（KG- Primary- Sec..etc）
- フィールドサイズをInt（11）から必要に応じて小さいものに変更
編集後のDBスキーマ
これらのことを実行した後、誰かが助けずにはいられません。将来、パフォーマンスのためにインデックスを追加する必要がありますか？インデックスはどこで必要になる可能性がありますか？
これがDB設計に興味のある人に役立つことを願っています。
回答
1 JohnHerbert Oct 22 2020 at 03:04
全体として、あなたの重要な関係は、私が簡単に自分の道を見つけることができるように、十分に率直で明確であると思います。モックアップして、最終的にストアドプロシージャやその他のプロセスをコーディングするときに、変更する場所がいくつか見つかるでしょう。これが私がそれを通して見たときの私の考えです。
- 親を保護者などのより一般的なものに置き換えます。この言語の使用は、祖父母や養親など、学生の他の権威者への扉を開くだけでなく、その人が緊急連絡先であるか、子供を迎えに行くことを許可されていることを示すフラグを可能にします。
- フィールド[Full_Name]を2つのフィールドに分けます。[Given_Name]と[Surname]。これは、プログラミング中に名前で並べ替えるときに役立ちます。（2人のウィリアムズ姉妹をレポートに並べて表示する方が、学校のすべてのメアリーをグループ化するよりも優れています）。
- [subject]テーブルの下の[term]フィールドを[class]テーブルに移動することをお勧めします。このフィールドは、Bobby Tablesが2010年の春または2009年の秋にそのクラスにいて、その特定の教師が特定の部屋にいたかどうかを示すために使用できます。それらの用語の日付範囲を持つ別のテーブルがあります。（ちなみに、INT（11）は少しやり過ぎかもしれません。100年の1週間の期間は、実際には5000の期間になり、INT（4）だけが必要になります）
- 学生を来年に昇進させるというテーマでは、[学生]テーブルの下の新しいフィールドで、教育の年を示す単純なINT（2）を使用して行うことができます。学年の終わりに実行されるストアドプロシージャは、獲得した単位を確認して、上に移動することができます。
- [subject]テーブルと[teacher]テーブルに数学、科学、英語などの学科を含めることも検討できます。これは、特に学校が特定のクラスの複数のセッションを持つのに十分な大きさである場合、すべての科学教師をグループ化するのに役立つか、その期間に利用可能なすべての歴史クラスを表示するために使用できます。