これは長期的なものだと思いますが、ここにあります。
基本的な質問は、開発チームが大規模で損傷したデータセットのデータ整合性をどのように修復し始めるかということです。
私が支援している会社には、数年の雑然とした、無効なデータ、壊れた参照などを含む巨大なMySQL / PHP5システムがあります。さらに、このデータは、GoogleAdWordsなどのいくつかのオンラインサービスのデータを参照しています。
そのため、ローカルデータベースに問題があり、ローカルとリモート（AdWordsなど）の関係にも問題があり、問題が悪化しています。
データの整合性の修復を開始するために共有できるヒント、コツ、またはベストプラクティスを誰かが持っていますか？また、迅速かつ継続的に追加および更新されるシステムでデータの整合性を維持するにはどうすればよいでしょうか。
大きな問題は、問題データについて何をしようとしているのかを特定することです。
そのためには、問題データがシステム/組織にどのように影響し、解決策がシステム/組織にどのように影響するかを確立する必要があります。
これは、分類の最初のレベルです。これを取得したら、特定の問題の特定を開始し、これから誤ったパターンを定義する一連のセマンティックルールを導き出す必要があります。
これにより、必要な修正を定義し、作業に効果的に優先順位を付け、リソースの使用率を計画できるようになります。また、ルート原因の削除に優先順位を付け、計画し、部分的に特定できるようにする必要があります。
「巨大」の定義が何であるかはわかりませんが、それに貢献しているプログラマーがたくさんいることを意味していると思います。その場合、データの整合性を管理するための標準と手順を確立する必要があります。パフォーマンスとセキュリティで行う必要があるのと同じように。
定義したルールは継続的なデータ管理の開始点ですが、これらを今後どのように適用するかを検討する必要があります-すべてのテーブルにタイムスタンプフィールドを追加する/特定のルールに違反する行を参照するテーブルを維持することは、データをチェックするたびにすべてのデータを処理する必要があります-前回チェックしてから変更されたものだけです-違反リストから削除されたケースとケースを追跡することをお勧めします追加されています。
適用された修正と対応するルール違反の記録を保持し、データを分析して、リファクタリングによってコードの保守性が向上する可能性のあるホットスポットを特定します。
要件と存在する「損傷」の程度によっては、新しいデータベースを作成し、アプリケーションを変更して両方を並行して更新することが賢明な場合があります。
有効なデータを新しいd/bにインポートし、その後、一連のプログレッシブ抽出によって有効なデータを追加し、深刻な損傷を受けたデータの回復を試みることが意味をなさなくなるまで、それらをインポートできます。確かに、破損していない不完全なデータベースは、破損したデータベースよりも優れており、有用です。破損している限り、「完全」とは言えません。