大学データベース用のスケーラブルなスキーマの設計

Question

私は大学のバックエンドを構築しようとしていますERPシステム。システムはLAMPに基づいています。

これらはシナリオです：

大学には5つの支部があります
各ブランチには4〜6のクラスがあります。
各クラスには80人の学生がいます。
各クラスにはほぼ6〜7科目があります。
約250の学部があります。
それぞれが1人以上の科目を教え、それぞれの指導計画を作成します。
1年に2学期があり、各学期に2つのテストが実施されます。
継続的評価（CA）は、科目ごとおよび学生ごとに行われます。 12実験と3課題マークで構成されています。
CAは、学期の終わりに用語ワークマークの計算につながります。

したがって、問題は、出席、継続的な評価、各学生のテストマークなどに関するデータを記録することです。

サンプルスキーマを作成しましたが、問題はそれがスケーラブルでないことです。次の理由により：

主題が40の講義である場合、クラスごとに単一の主題の出席を記録するには、ほぼ80 * 40 = 3200のレコードが必要です。では、各学期にさらに6科目についてはどうでしょうか。
ここを見てください

だから私の質問は：

どのテーブルをそのまま保持するか（つまり、1回だけ作成する必要があります）、どのテーブルを動的に、どの間隔で作成する必要がありますか？ [つまり、年度ごと/学期ごと/その他の提案]
データ検索を最適化する方法は？.
スキーマを適切にスケーリングできるように再設計する方法。
データベース内の各テーブルのサイズを見積もるにはどうすればよいですか。 nullまたは空のままのフィールドがスペースを占めるかどうか（サイズ計算で考慮されるかどうか）

何か提案や助けを事前にありがとう。

phasetwenty · Accepted Answer

初期対応

予備事項：

実際問題として、作成/変更された時間の日付フィールドを投入すると便利です。データの問題をデバッグするときに、作業がはるかに簡単になります。ルックアップテーブルではないほとんどすべてのテーブルは、その恩恵を受けるでしょう。テーブルが追記型である場合、前述の変更された時間列を検討してください。
パスワードをプレーンテキストで保存しないでください。それはこの質問の範囲を超えていますが、私はそれを言及するのに時間をかけると思いました。

とは言っても、実際に問題をバックアップするためのデータが得られるまで、スケーラビリティなどについては時期尚早に心配していると思います。そうは言っても、私には簡単な提案が1つあります。

主題が40の講義である場合、クラスごとに単一の主題の出席を記録するには、ほぼ80 * 40 = 3200のレコードが必要です。では、各学期にさらに6科目についてはどうでしょうか。

多くのレコードを追加しているのは事実ですが、これらのレコードはこれまでのところ...各10バイトですか？データ型のサイズを調べるつもりはありませんが、10バイト行でバンクを壊すわけではありません。ユーザーは常に出席者を利用可能にしたいのですが、保持ポリシーに同意することで、成長を抑え、数年前から出席者レコードを整理できるようになると思われます。

それでも、最適化する余地はあります。 1対1の関係で各Studentの出席を記録するのではなく、「出席」または「欠席」の小さい方を選択して出席を記録し、それだけを記録することをお勧めします。たとえば、ほとんどの学生が講義に行くと仮定すると、「欠席」を選択します。つまり、Attendanceテーブルには、講義を欠席したStudentsの行のみが含まれます。 StudentがAttendanceテーブルに行を持っている場合、講義を欠席しました。それ以外の場合、彼は出席しました。もちろん、そのような場合、AttendanceはAbsenceなどの名前に変更する必要があります。

利害関係者がスキーマにデータを追加したい場合に何をするかを検討するために、より多くの時間を費やしてください。たとえば、カテゴリやグループ、エイリアス、予備の名前、予備のメールの追加などです。

動的テーブル生成について

どのテーブルをそのまま保持するか（つまり、1回だけ作成する必要があります）、どのテーブルを動的に、どの間隔で作成する必要がありますか？ [つまり、年度ごと/学期ごと/その他の提案]

パフォーマンスの問題がまだ何であるかがわからないため、これは時期尚早の懸念事項です。リリース後にパフォーマンスの悪いテーブルを探し、必要に応じてアーカイブプロセスを構築する傾向があります。

アプリケーションに影響を与えるライブホスト上のデータベーススキーマを編集する必要があるため、動的にテーブルを作成することはお勧めしません。タイプミスを犯した場合、アプリケーションがダウンする可能性があります。質問に答えるために、行レベルでデータをアーカイブすることをお勧めします。

古いデータの可用性を高くし、アクセス頻度を低くする必要がある場合は、アプリケーションの個別のモジュールを使用し、独自の個別のデータベースを使用してデータを表示できます。このデータベースは、ライブ/アクティブモジュールからアーカイブモジュールに（メンテナンスウィンドウ中に）行を移動する外部プロセスによって入力できます。

高可用性である必要がない場合は、（メンテナンス期間中に）ライブデータベースから行をエクスポートして、適切にバックアップされ、開発者ツールを使用してオンデマンドで確認できる圧縮アーカイブにエクスポートできます。

このアプローチの利点は、行の操作によってサイトが停止しないことです。最悪の場合、しばらくの間一部のデータが欠落するか、パフォーマンスが低下します。

リード開発者として、ニーズが何であるかを決定し、それに応じて行動するのはあなた次第です。繰り返しになりますが、具体的な問題が発生するまで、この種の作業を延期することをお勧めします。