DateTime 列に startingDate を格納しているテーブルがあります。
startingDate値を取得したら、計算することになっています
- 日数、
- number_of_weeks
- number_of_months および
- 年数
startingDate から現在の日付までのすべて。
これらの値をアプリケーションの 2 つ以上の場所で使用し、アプリケーションの応答時間を重視する場合、テーブルを直接クエリできるように、ビューで計算を行うか、それぞれの計算列を作成しますか?
2026 次
3 に答える
0
計算列は保守が容易で、問題に対する理想的なソリューションを提供します。私は最近、そのようなソリューションを使用しました。ただし、値は、行がテーブルに INSERT されたときではなく、要求されたとき (SELECT されたとき) に計算されることに注意してください。そのため、パフォーマンスは依然として問題になる可能性があります。アプリケーション サーバーからデータベース サーバーに作業をオフロードできる場合は、これで問題ありません。ビューも要求されるまで (具体化されない限り) 存在しないため、実行時にオーバーヘッドが発生しますが、アプリケーション サーバーではなくデータベース サーバー上にあります。
于 2013-04-09T07:18:53.710 に答える
0
ほとんどすべてのことと同様に、場合によって異なります。
@RedXが示唆するように、どちらの方法でもパフォーマンスの違いはほとんどないため、それらをどのように使用するかが問題になります。私にとって、これはもっと感じることです。
それらを複数回使用しても、すぐにビューまたは計算列に移動する必要はありません。少数の場所または少量のコード パスでのみ使用する場合は、それらの場所でインラインで計算するか、CTE を使用します。しかし、広く使用されているか頻繁に使用されている場合は、ビューまたは計算列に同意します。
また、ORM ツールを介して使用できるようにする場合は、ビューまたは cc でそれらを使用することもできます。
これらの「計算された列」を個別に使用していますか、それともセットで使用していますか? それらをセットで使用する場合、それらすべてが含まれていることを示すテーブルのビューが必要になるでしょう。
それらが必要な場合、通常、それらを特定の他のテーブルのデータに関連付けたいですか? もしそうなら、それは見解を示唆するでしょう。
これらの計算値の元のテーブルに基づいて更新していますか? もしそうなら、計算された列がこれらの場合にビューに参加するのを避けたいです。
于 2013-12-02T17:05:06.043 に答える