実際、私は学術機関向けのソフトウェアを構築しているので、いくつかの質問の答えを知りたかっただけです:
ご存知のように、毎年いくつかの新しいデータが生成され（新規入学のために）、一部はアップグレードされます。したがって、すべてのデータを学年ごとに (ac_year のような列として) 1 つの単一のテーブルに格納するか、年ごとに個別のテーブルを作成する必要があります。また、学生に関するクラス、マーク、料金、ホステルなどの情報を格納するさまざまなテーブルがあります。したがって、料金のような各情報は、料金-2010 料金-2011 料金-2012 のような異なるテーブルに格納されます...
または、列として年を含む 1 つの料金表で。
もう1つのポイントは、1〜2年後にデータベースが重くなるため、1つのテーブルで1年間のデータをバックアップすることが可能になるということです（年を列として持つ料金のように）？
また、SQL Server 2005 を念頭に置いて回答してください。
ありがとう
質問の言い方からすると、答えは明らかに、データを 1 つのテーブルに格納し、年 (または日付またはその他の情報) を列として格納することです。これは単に正しいことです。あなたは時間をかけて同じエンティティを扱っています。
1 つの例外は、ある年から次の年にかけてフィールドが大幅に変化する場合です。あなたのテーブルの場合はそうではないと思います。
データベースが本当に大きくなっている場合は、テーブルを時間で分割することを検討できます。各パーティションは、1 年分のデータになります。これにより、1 年分のアクセスのみが必要なクエリが高速化されます。また、データのバックアップと復元にも役立ちます。これは、最終的に探しているソリューションになる可能性があります。
「本当に大きくなる」とは、テーブル内の少なくとも数百万行を意味します。テーブルに数百万の行がある場合でも、ほとんどのクエリは、適切なインデックスを備えたまともなハードウェアでおそらく問題なく実行されます。
時間の制約に基づいて複数のテーブルにデータを格納することは一般的ではありません。すべてを 1 つのテーブルに格納することをお勧めします。将来、古いデータのアーカイブを検討するかもしれませんが、パフォーマンスが問題になるまでにはまだかなりの時間がかかります。
異なるプロパティごとに新しいエンティティを作成するよりも、エンティティに新しいプロパティを追加する方が常に良いオプションです。このようにして、メンテナンスとクエリがはるかに簡単になります。クエリのパフォーマンスに関しては、データとデータベースの内部問題について心配する必要はありません。実際のパフォーマンスの問題が発生した場合、あなたの状況のように年にインデックスを作成するなどの多くの解決策があります。