すべての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でこれらのフィールドをマップする必要がある場合も、そうでない場合もあります。これは、単にアプリケーションユーザーにこれらのフィールドを変更させたくないため、メンテナンスとデバッグに役立ち、ビジネスロジックではほとんど使用しないためです。私は両方の方法でそれをした店で働きました、そして、私は率直に言ってこれについての多くの意見を持っていません。

データベースレベルでそのような機能を実装する人的コストは、たとえ誇張されたものであっても、そのメリットは依然としてはるかに大きく、おそらく、壮大な胸を打つような試合でミーティングをハイジャックしてスパーリングする偉大な技術者たちのプロジェクトの集合的な頭脳力よりもおそらく小さいでしょう。数時間の会議がプロジェクトの寿命に与える影響を集計すると、おそらくそれらが高価であることに驚かないでしょう。これらすべての人々の時間給と福利厚生の合計を想像してみてください。

...男がより明確な発言をすればするほど、彼は間違いなく間違いを犯しやすくなります...-タイラー・ダーデン

これはブランケット「標準」に適用されますが、一部のテーブルではこれが大きな勝利になる可能性がありますが、すべてのテーブルで無駄なノイズと維持するコードまたは維持することを忘れるコードが増える可能性があります。

ここでバランスを取る必要があります。それが意思決定者にプッシュすべきものです。

心から同意します。すべてのデータベースのほぼすべてのテーブルには、作成日と更新日という少なくとも2つのフィールドが必要です。作成日と更新日を入力する必要がある多くの理由があります。先人が述べた明らかな理由のために...それは監査です。

私はシステムとデータベースを25年間設計し、何百ものクライアントで働いてきました。これを必要としなかった単一のクライアントはありません。

これを行うには、2つの基本的な方法があります。

1-最初のプラクティスは、データベースに作業を行わせ、それをテーブル設計に直接入れます。これは最低限のものです、私はお勧めします。

2-私が好むもう1つの方法は、複製ツールを使用してこれを処理することです。オーバーヘッドはほとんどなく、開発チームに費用はかかりません。ただし、ツールは高価です。もう1つの利点は、このタイプのツールを使用すると、削除プロセスをはるかに簡単に監査できることです。レプリケーションツールがなければ、監査テーブルを作成し、削除のトリガーを起動する必要があります-私の意見では良い方法ではありません。

これらのフィールドを持つことのもう1つの利点は、OLTPシステム用に常に構築されるデータウェアハウスとODSです。それなしで増分データを効果的にプルすることはできません。そうしないと、毎日DB全体をリロードする必要があります。

これら2つの日付を入力することには、他にも多くのビジネス上の理由がありますが、ここでは詳しく説明しません。あなたの宿題をしなさい、そして私はあなたがこれらの２つの単純なフィールドに入れてあなたがとても幸せになるであろう道を３－６－１２－４８ヶ月確信している。

可能な限り両方のソリューションを実装し、通常は推奨しています。

作成日があり、データベースの列によって作成されているため、データの問題を追跡するのに非常に役立ちました。元に戻す必要がある場合は、完全な監査テーブルで正しいレコードを見つけるのに役立ちます（非常に大きなテーブルのどこを参照すればよいかがわかっているため）。彼女は列の作成者と変更者も追加する必要があります。特に完全な監査がない場合、誰がデータを入力したかを知ることは本当に役立ちます。

何らかの形式の監査を必要としないエンタープライズアプリケーションは考えられません。どうやら上司は、比較的穏やかな監査だけが必要だと考えています。個人的に、私はあなたの会社が依存しているデータを含むすべてのデータベースの完全な監査を好みます（バックアップを復元するよりも監査テーブルからこれらの2000の悪いレコードを元に戻すのは非常に簡単です）そして私がまったく財務情報がある場合それを要求しますこの種のことは、詐欺を犯している人々を捕まえるのに役立つことを見てきました。すべての監査はデータベースレベルで行う必要があります。

このデータはどのように役立ちますか？まず、古いデータ（リビジョン）を検索するタイミングを絞り込み、データが入力された時点でアクティブだったプログラムのバージョンを確認するのに役立ちます。そのため、2011年7月6日に公開されたバージョン2.3でその問題を修正し、8月7日に挿入されたレコードで同じ問題が見つかった場合、修正はうまくいかなかった可能性があります。古いデータに戻す必要がある場合、完全な監査がない場合に古いデータを見つけることができるバックアップのバージョンが通知されます。

開発者は、データを長期間維持する必要があり、不良データを誰かが修正する必要があると考えることはめったにありません。そのようなことをすることは、そのようなことをしなければならない私たちにとって非常に貴重です。あなたの上司は正しいですが、彼女は監査で十分に行ったとは思いません。これらの列とトリガーを追加するのにかかる非常に短い時間を正当化するために修正するのが簡単な、本当に深刻な問題が1つだけかかります。

これはスクリプト化し、作成するすべてのデータベースに適用できるため、ワークロードは意味がありません。トリガーとともにすべてのテーブルに列を追加します。ビルドで実行することを忘れないでください。

クライアントが望んでいる限り、あなたが彼らに合うように彼らをあなたのアプリに統合するためにあなたに彼らにあなたに支払いをさせることができます。多くの人は、誰が最後にいつ変更したかなど、レコードに関する追加情報を見るのが好きです。見つけたり嘘をついたりするために全員にメールを送る必要はありません。誰かがレコードを見るたびにログを照会する必要はありません。

それをデータベースに入れて、念のためそこに置いておくのはそれほど難しくなく、フィールドを利用する追加機能に課金したり、システムを使用しているクライアントの数に関するフィードバックを与えたりすることができます。

これは実装するのがかなり簡単です（合計で1〜3日）ので、私の意見では、その存続期間中にアプリケーションにどれだけの価値を追加するかを考えます。

最初に、列を追加するにはalter tableステートメントが必要です。altertableはすべて同じです（テーブル名を除く）。したがって、必要なすべてのテーブルに対してalter SQLステートメントを生成するコードを記述するスクリプトを書くことができます。 。NULLが既存のデータを考慮し、列の存在を確認して再実行できるようにする必要があります。

次に、列に対して、GetUTCDate（）などのデフォルト値を使用すると（SQL Server、Oracleは異なる場合があります）、挿入時のコーディングの追加を解決するため、デフォルト値が挿入されるため、コードベースはinsertsステートメントのいずれに対しても変更する必要がありません中古。

データの更新（最終変更への変更）は、更新トリガーで解決できます。繰り返しますが、このトリガーはすべてのテーブルでほぼ同じであるため、このトリガーコード（SQL）は、既存のテーブルに対しても生成される可能性があります。

潜在的に多くのSQLスクリプトコード（テーブルの数によって異なります）がありますが、繰り返し可能なパターンなので、既存のDBスキーマを調べることでコードを生成できます。