すべてのDBテーブルの作成日と最終更新日フィールドを含めて標準化することには意味がありますか？
私の上司は現在、いくつかの開発標準をチームに適用しようとしています。そのため、昨日会議を開き、彼女が育てるまではほとんど順調だった標準について話し合いました。
- すべてのDBテーブルには、トリガーによって更新されるCreatedDateおよびLastUpdatedDate列があります。
この時点で、私たちのチームは意見の分裂に苦しみました。私たちの半分は、すべてのテーブルでこれを行うことは、ほとんど利益のない大量の作業であると考えています（固定予算プロジェクトに取り組んでいるため、コストは会社の利益から生じます）。後半はそれがプロジェクトのサポートに役立つと信じています。
私は元キャンプにしっかりと入っています。一部の外部のケースでは追加の列によってサポート性が向上することを理解していますが、私の意見では、最初に列を追加するために必要な作業量とメンテナンスにより、より多くの時間を費やすことができますユニットテストや負荷テストなどの重要なこと。また、これらの追加の列によってORMを使用するのがより厄介になると確信しています。主にC＃とOracleを使用していることを念頭に置いてください。
だから、私の質問は2つあります：
- 私は正しいキャンプにいますか？私は世界的に有名なデータベーススキルを持っているとは主張していません。そのため、これは副作用がなく、簡単に追加できるかもしれません。
- 標準に関する会議がスラグマッチに発展する状況にどのように対処しますか？この標準が長期的に私たちを助けることにならないことをどうやって本当に販売できますか？
これはかなり一般的な方法ですが、サポート性が主な利点であるとは言えません。このアプローチの真の利点は、監査証跡を保持することです。また、最後の更新を行ったユーザーのユーザー名を含む追加の列があるのも一般的な場所です。
財務データや機密データを扱っている場合は、 [〜＃〜] pci [〜＃〜] ＆ [〜 ＃〜] sox [〜＃〜] コンプライアンス。これらの仕様を満たすには、包括的な監査証跡を持つことが不可欠です。
免責事項：ただし、データベースの監査証跡を達成するためのより良い方法があります> https://stackoverflow.com/questions/1051449/ideas-on-database-design-for-capturing-audit-trails
前者の引数は無効です。これは、データベースで管理されているいくつかのタイムスタンプフィールドを一連のテーブルに追加することは難しい作業ではないためです。これは実際には、ジュニアまたはインターンに与える一種の心麻痺タスクであり、彼らは、2週間のスプリントで時間を割いて簡単にそれを行うことができました。
これらのフィールドをORMでマップする必要がある場合とない場合もあります。これは、アプリケーションユーザーがこれらのフィールドを変更することを望まないため、およびメンテナンスやデバッグに役立ち、ビジネスロジックで使用されることはほとんどないためです。私はそれを両方の方法で行った店で働いていました、そして率直に言って、私はこれについてどちらの方法についてもあまり意見を持っていません。
データベースレベルでこのような機能を実装する際の人的コストを大幅に上回る場合でも、メリットは確かにはるかに大きく、おそらくプロジェクトの総力よりも、会議をハイジャックして壮大な胸の激しい試合でそれを打ち砕くほどではありません。数時間の会議がプロジェクトの寿命に与える影響を集計すると、多額の費用がかかることに驚くことはないでしょう。これらすべての人々の総時間給と福利厚生を合わせたものを想像してみてください。
...男性がより明確な陳述をするほど、彼は間違いなく間違っている可能性が高くなります...-タイラー・ダーデン
これは包括的な「標準」に適用されますが、一部のテーブルではこれは大きな勝利になる可能性がありますが、everyテーブルでは、無意味なノイズと維持するコード、または維持するのを忘れるコードが増える可能性があります。
ここでバランスを取る必要があります。それを意思決定者にプッシュする必要があります。
私は心から同意します。すべてのデータベースのほぼすべてのテーブルには、少なくとも2つのフィールド（作成日および更新日）が必要です。作成日と更新日を入れる必要がある理由はたくさんあります。以前の人々が述べた明白な理由のために…それは監査です。
私は25年間システムとデータベースを設計しており、何百人ものクライアントのために働いてきました。これを必要としない単一のクライアントはありません。
これを行うには、2つの基本的な方法があります。
1-最初のプラクティスは、データベースに作業を任せ、それをテーブル設計に直接入れることです。これは最低限必要なことです。
2-私が好むもう1つの方法は、複製ツールを使用してこれを処理することです。オーバーヘッドはほとんどなく、DEVチームに費用はかかりません。ただし、ツールは高価です。もう1つの利点は、このタイプのツールを使用すると、削除プロセスを簡単に監査できることです。レプリケーションツールがなければ、監査テーブルを作成し、削除のトリガーを起動する必要がありますが、私の意見ではお勧めできません。
これらのフィールドを使用するもう1つの利点は、OLTPシステムでは常に構築されるデータウェアハウスとODSです。それがないと、増分データを効果的にプルすることはできません。それ以外の場合、毎日DB全体をリロードする必要があるリスクがあります。 。
この2つの日付を入力する理由は他にもたくさんありますが、ここでは詳しく説明しません。宿題をやれば、3-6-12-48か月後には、この2つの単純なフィールドに入れてくれてとても嬉しいです。
私は実装しており、通常は可能な限り両方のソリューションを推奨しています。
作成日とデータベースの列によって作成され、データの問題を追跡するのに非常に役立ちました。元に戻す必要がある場合は、完全な監査テーブルで正しいレコードを見つけるのに役立ちます（非常に大きなテーブルのどこにあるかがわかっているため）。また、作成者および変更者の列も追加する必要があります。特に完全な監査がない場合は、誰がデータを入力したかを知ることが本当に役立ちます。
なんらかの形での監査を必要としないエンタープライズアプリケーションは考えられません。どうやらあなたの上司は、比較的穏やかな監査のみが必要であると考えています。個人的には、会社が依存しているデータを含むすべてのデータベースを完全に監査することを好みます（バックアップを復元するよりも、監査テーブルから2000個の不良レコードを元に戻す方がはるかに簡単です）。このタイプのものは、詐欺を犯している人々を捕まえるのを助けるのを見ました。すべての監査はデータベースレベルで行う必要があります。
このデータはどのように役立ちますか？まず、古いデータ（リビジョン）を探すタイミングを絞り込み、データが入力されたときにプログラムのどのバージョンがアクティブであったかを確認するのに役立ちます。そのため、2011年7月6日に公開されたバージョン2.3でその問題を修正し、8月7日に挿入されたレコードで同じ問題を発見した場合、修正は適切ではなかった可能性があります。古いデータに戻す必要がある場合は、完全な監査がない場合に、古いデータを見つけることができるバックアップのバージョンがわかります。
開発者は、データを長期間にわたって維持する必要があり、不正なデータを誰かが修正する必要があると考えることはほとんどありません。そのようなことをすることは、そのようなことをしなければならない私たちにとって非常に価値があります。あなたの上司は正しいですが、彼女は監査を十分に行っていないと思います。これらの列とトリガーを追加するのにかかる非常に短い時間を正当化するために修正するのが簡単な本当に深刻な問題が1つだけ必要です。
これはスクリプト化して、これから作成するすべてのデータベースに適用できるため、ワークロードは問題ありません。トリガーとともにすべてのテーブルに列を追加します。ビルドで実行することを忘れないでください。
クライアントが望んでいる限り、彼らにお金を払って、彼らが適切だと思うようにあなたのアプリにそれらを統合させることができます。多くの人は、誰がいつ最後に作成/変更したかなど、レコードに関する追加情報を見たいと思っています。見つけて嘘をつくためにメールを全員に送る必要はありません。誰かがレコードを見るたびにログをクエリする必要はありません。
それをデータベースに入れて、念のためそこに置くことはそれほど難しくなく、フィールドを利用する追加機能に課金したり、クライアントがシステムを使用している量についてフィードバックを提供したりすることができます。
これは実装するのはかなり簡単です（多分合計で1〜3日）。したがって、私の考えでは、アプリケーションの存続期間中にどれだけの価値をアプリケーションに追加するかです。
最初に、列を追加するためにalter tableステートメントが必要であり、alter tableはすべて同じ（テーブル名を除く）であるため、必要なすべてのテーブルに対してコードを生成するalter SQLステートメントを生成するスクリプトを記述できます。 。 NULLが既存のデータを考慮し、列が存在するかどうかを確認して再実行できるようにする必要があります。
次に、列について、GetUTCDate（）（SQL Server、Oracleは異なる可能性があります）などのデフォルト値を使用して、挿入時のコーディングの追加を解決します。したがって、デフォルト値は中古。
データの更新（最終変更への変更）は、更新トリガーで解決できます。繰り返しますが、このトリガーはすべてのテーブルでほぼ同じであるため、このトリガーコード（SQL）は、既存のテーブルに対してもコードを生成できます。
多数のSQLスクリプトコードが存在する可能性がありますが（テーブルの数によって異なります）、これは繰り返し可能なパターンであるため、既存のDBスキーマを調べることでコードを生成できます。