クエリが誤って削除される可能性があるため、さらに問題が発生します。
これがバージョン管理ソフトウェアの目的です。また、ビューを「誤って」削除できる場合は、テーブルを誤って削除する可能性があります。
彼は、過去の経験からすべてのシステムで行ったように、第 2 正規形で十分だと言いました。
それから彼は十分な経験を持っていません。特に会計では。
私は、部下が 5NF でパフォーマンスの高い設計をしてくれると主張することで有名 (または悪名高い) です。それができない場合は、おそらく a) 5NF が何であるかを知らないか、b) すべての行に ID 番号が必要だと考えています。(すべての行に ID 番号があると、必要な結合の数が増え、多くの場合、パフォーマンスが低下し、正規化とは何の関係もありません。) これらはどちらも教育の良い機会です。
BCNFで十分かもしれません。2NF は通常そうではありません。
この戦いに負けた場合は、CHECK() 制約を主張して、合計が常に正しいことを確認してください。
私たちと一緒に働いている人 (十分な技術的知識がない) は、十分な属性/行を持たないテーブルから必要なクエリを作成できません。
いくつかのビューを追加すると、短期的には役立ちます。更新可能なビューをいくつか追加する必要がある場合があります。ただし、本番グレードの登録システムで会計データを扱うことになる人に、一定レベルの技術知識を要求する権利があります。
会計、給与計算、在庫、購買などの他のシステムは、登録システムと統合する予定です。その場合、クエリにアクセスせずに、新しい各システム データベースを登録システム データベースに直接接続することをお勧めします。
ビュー (クエリ) とテーブルは、1 つの名前空間を共有します。クライアントコードは、「ビューではなくテーブルに接続したいので、'student_payments' という名前にする必要があります」とは言いません。クライアント コードは、「'student_payments' に接続する」というだけです。
とはいえ、支払表に挿入する権限を持つ人は、支払表に正しく挿入する方法をよく知っています。他の列の計算の結果である列を含める必要がある場合は、CHECK() 制約を主張してください。
すべてのクライアント アクセスがストアド プロシージャを介して行われ、クライアント コードがテーブルに直接アクセスできないように設計されたシステムがあります。このアプローチは、有効なトランザクションを一度に多数のテーブルに挿入する必要がある場合に非常に有効です。
彼は、各学生の計算された平均成績などのすべての従属行もテーブルに含める必要があると主張しました。なぜなら、必要なのは物理データであり、ビューによって再計算されるものではないからです。
必要なのは、データベースが常に正しい答えを提供することです。
さらに重要なことは、彼がすべてのトランザクションをデータベースに入力することを望んでいたことだと思います。取引のバランスを取るための借方と貸方の場合と同様。
最後に、賢明な何か。金融取引は通常、挿入されるだけです。それらが正しくない場合、それらは更新または削除されません。代わりに、補償トランザクションを挿入します。（そして、その理由を願っています。）
実際問題として、最初のリリースには計算列を含めません。それらの不在が実際のパフォーマンスの問題を引き起こした場合にのみ、それらを追加します。
そうは言っても、実際のパフォーマンスの問題を特定するには、かなり高いハードルがあります。Vinny Vice-president がクエリが返されるまで 5 秒待たなければならない場合、それは実際のパフォーマンスの問題ではありません。5 秒かかるクエリが他のクエリをブロックし、全体的なパフォーマンスを毎日低下させている場合、それは実際のパフォーマンスの問題です。
1 つの SELECT ステートメントの動作に基づいてパフォーマンスの問題を判断しないでください。パフォーマンスの問題は、システム全体の動作に基づいて判断するのが理想的です。実際には、SQL ステートメントの代表的なサンプルの動作に基づいています。パフォーマンスの問題が発生する前に、代表的な SELECT、INSERT、および DELETE ステートメントを選択してください。代表的なサンプル データでテストし、少なくともタイミングを保存します。理想的には、実行計画とタイミングを保存します。
テーブルに「実際の」データを含めるためだけに計算列を含めることはしません。
計算結果を保存することによって実際のパフォーマンスの問題を解決しなければならない場合、これらのことの少なくとも1 つを実行せずに解放することはありません。
- 制約が単一行での計算を必要とする場合、計算された値が常に正しいことを保証するために CHECK() 制約を含めます。
- 制約で複数行にわたる計算が必要な場合は、制約を実装するためのアサーションまたはトリガーを含めます。また、dbms のドキュメントを注意深く確認し、たとえばトリガーが起動しない可能性があるインスタンスを探します。(一部のプラットフォームでは、一括読み込み中にトリガーが起動しません。)
- CHECK() 制約、アサーション、またはトリガーを使用できない場合は、実際の合計が一致しないデータを定期的に検索するために、できればストアド プロシージャまたは同等のコードで何らかの管理プロシージャを実装します。予想合計。それを SP に実装できない場合は、cron ジョブの下で実行されるアプリケーション コードで実装します。他のプロセスに実質的な影響を与えずにこれを行う方法はたくさんあります。
多くの場合、宣言された制約も使用している場合でも、データの欠落や計算ミスをチェックする定期的な管理手順を実装します。十分な権限を持っている人なら誰でも、正当な理由、悪い理由、または理由なしで、制約を削除または無効にすることができます。(自分自身を含め、高い特権を持つユーザーは、最も危険なユーザーです。)