質問

背景

私はCS1年生で、父が経営する中小企業でパートタイムで働いています。実世界でのアプリケーション開発の経験はありません。Pythonでスクリプトを書いたり、C言語のコースワークをしたことはありますが、このようなものはありません。

私の父は小さな研修事業を行っており、現在、すべての授業は外部のWebアプリケーションを介してスケジュール、記録、フォローアップされています。エクスポート/"レポート"機能がありますが、それは非常に一般的なもので、私たちは特定のレポートを必要としています。私たちは、クエリを実行するために実際のデータベースにアクセスすることができません。カスタムレポートシステムを構築するよう依頼されています。

私のアイデアは、一般的なCSVエクスポートを作成し、（おそらくPythonで）毎晩オフィスでホストされているMySQLデータベースにインポートし、そこから必要な特定のクエリを実行できるようにすることです。私はデータベースの経験がありませんが、非常に基本的なことは理解しています。データベースの作成と通常のフォームについて少し読んだことがあります。

近々、海外のクライアントが来るかもしれないので、その時にデータベースが爆発しないようにしたいです。また、現在、いくつかの大企業をクライアントとして持っており、それぞれ異なる部門を持っています（例：ACME親会社、ACMEヘルスケア部門、ACMEボディケア部門など）。

私が考えたスキーマは以下の通りです。

1. クライアントから見て
   • クライアントがメインテーブル
   • 顧客は所属する部門にリンクされている
     • 部署が全国に散らばっていることがある。人事部はロンドン、マーケティング部はスウォンジー、など。
     • 部門は会社の部門と連動している
   • 部門は親会社にリンクしています
2. クラスから見た場合。
   • Sessionsはメインテーブル
     • 各セッションに教師がリンクされています
     • 各セッションにステータスIDが付与されます。例：0 - 終了、1 - キャンセル
     • セッションは、任意の大きさのパックにグループ化されます。
   • 各パックは、クライアントに割り当てられる

スキーマを紙に書いて、第3形式に正規化するように設計しました。そして、それを MySQL Workbench に接続すると、すべてきれいに仕上げてくれました。

( フルサイズの画像はこちら )

<サブ (出典 maian.org )

実行するクエリーの例

• クレジットの残っている顧客のうち、非アクティブな顧客（今後クラスの予定がない顧客）はどれか
• クライアント／部署／部門ごとの出席率はどうか（各セッションのステータスIDで測定しています）
• ある講師が1ヶ月に行った授業の数
• 出席率の低いクライアントにフラグを付ける
• 人事部向けに、所属する人の出勤率をカスタムレポート化

質問（複数可）

• これはオーバーエンジニアリングでしょうか、それとも正しい方向でしょうか？
• ほとんどのクエリで複数のテーブルを結合する必要があるため、パフォーマンスが大きく低下するのではないでしょうか？
• 一般的なクエリになると思われるので、クライアントに「lastsession」カラムを追加しました。これは良いアイデアでしょうか、それともデータベースを厳密に正規化した方が良いのでしょうか？

お忙しい中、ありがとうございました。

解決方法は？

ご質問に対する回答をいくつかご紹介します。

1) このような問題に初めて取り組む人にとっては、かなり的を射ていると思います。 この質問に対する他の人からの指摘は、これまでのところ、ほぼ網羅されていると思います。よくやった

2 & 3) あなたが受けるパフォーマンスのヒットは、あなたの特定のクエリ/プロシージャと、より重要なレコードの量に対して適切なインデックスを持ち、最適化することに大きく依存します。 メインテーブルのレコード数が100万を超えない限り、十分なメインストリーム設計の軌道に乗っているようなので、妥当なハードウェアであればパフォーマンスは問題にならないでしょう。

とはいえ、これは質問3に関連することですが、あなたのスタート時点では、パフォーマンスや正規化のオーソドックスさに対する過度の心配をする必要はないでしょう。 これは、あなたが構築しているレポートサーバーであって、トランザクションベースのアプリケーションバックエンドではありませんし、パフォーマンスや正規化の重要性に関しても、はるかに異なるプロファイルを持っているでしょう。 ライブサインアップとスケジューリングアプリケーションを支えるデータベースは、データを返すのに数秒かかるようなクエリに注意する必要があります。 レポートサーバーの機能は、複雑で長いクエリに対してより寛容であるだけでなく、パフォーマンスを向上させるための戦略も大きく異なっています。

例えば、トランザクションベースのアプリケーション環境では、ストアドプロシージャやテーブル構造を徹底的にリファクタリングしたり、よくリクエストされる少量のデータに対してキャッシュ戦略を開発することが、パフォーマンス向上の選択肢に含まれるかもしれません。 レポート環境では、このようなことはもちろん可能ですが、スナップショットのメカニズムを導入することで、パフォーマンスにさらに大きな影響を与えることができます。スケジュールされたプロセスが実行され、事前に設定されたレポートが保存され、ユーザーはリクエストごとにデータベース層に負荷をかけることなくスナップショットデータにアクセスすることができます。

以上、長文になりましたが、作成するデータベースの役割によって、採用する設計方針やトリックが異なる可能性があることを説明しました。 ご参考になれば幸いです。