恐ろしく設計されたデータベースの上に良いコードを書く希望はありますか？
これが私の苦境です。私が最近継承したいくつかのプログラムの1つは、バックエンドの恐ろしいデータベースで構築されています。それの尊敬された作成者はどうやら関係概念を高く評価しませんでした。一意のクライアントIDとして名前が付けられた、すべてのクライアントのテーブル。謎めいた名前の83個のフィールド。コードはすべて手続き型で、数十のインラインSQLステートメントが連結されています。
同じデータベースで実行される重要な補助アプリケーションが提供されていなかったので、私はそれを最初から再作成する必要があります。私は唯一の開発者です。私の時間の少なくとも半分が運用関連のものに費やされているので、私の主な責任でさえありません。やむを得ない期限が今から30日間設定されています。
私の未経験にもかかわらず、私はこのデータベースと既存のアプリケーションを以前よりもはるかにうまく設計できたと確信していますが、データベースを変更し、既存のアプリケーションを調整することは現実的ではないと思います。追加のアプリケーションをこれですばやく作成する必要がある間に、何かを壊します。
それで、私がひどいデータベースで立ち往生していると仮定しましょう。そのような悪い構造で作業する必要がある場合、それに準拠するように書いたものは、何かが完全に壊れるか、新しい機能が必要になるまで棚上げされる技術的負債の山に追加されますか？どうすればこの状況にアプローチして、うまくいけば機能的なアプリケーション以外に何か良いことを得ることができますか？
編集：誰かが興味を持った場合に備えて、この恐ろしいデータベースとその上で実行されていたアプリケーションを破棄してしまいました。補助的なアプリケーションの作成（私はこれの設定には関与していませんでした）を最終的に2人の異なる請負業者に外部委託しましたが、両方の請負業者が私たちに失敗し、何も達成しませんでした。私は結局、今日でも使用されている3日間で、恐ろしく部分的に機能する修正のハックを急いで行わなければならなくなりました。
希望はありますが、特にデータベース設計が恐ろしいものであることに誰も気付いていない場合は、困難な戦いになります。抽象化レイヤーを使用して、いらいらを抽象化することもできますが、それだけの価値はないでしょう。
私のアドバイスは、アプリケーション自体がクリーンで適切に設計されるように、データベースに対して十分な抽象化を作成することです。そうすればifデータベースを修正できます。データベースの設計方法を気にしないので、アプリケーションは影響を受けません。
これは、適切な場所にあるデータベースを扱うときに私が通常使用するアプローチであり、多くの場合、ゼロ思考で設計されています。いくつかのサービスレイヤーがゲートウェイ/リポジトリと通信する、リポジトリまたはゲートウェイパターンのいくつかの選択アプリケーションは、貧弱な設計の隔離に役立つはずです。
すべてのDBを処理するインターフェイスレイヤーを作成し、それとインターフェイスするアプリを作成します。データベースが「修正」された場合は、「インターフェース」を置き換える/更新するだけです。このアプローチにより、不良データベースや、他のアプリケーションに供給されていて混乱することができないデータベースを処理するときに、多くの時間を節約できました。
データベースは、他のコードと同じようにリファクタリングできます。記述する必要のあるコードの影響を受ける部分を修正し、テストを記述して、他に問題がないことを確認します。他のリファクタリングと同様に、一度に少しずつ実行します。混乱のクリーンアップを開始するのに役立つデータベースリファクタリングに関する優れた本があります。 http://www.Amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1
他にもありますが、私は個人的にこれを読んでテクニックを使って作業しました。
また、ビューを作成してデータベースのクエリに必要な方法を再構築して、厄介な変換作業を行い、クエリしやすい構造にすることも忘れないでください。
痛い…あなたは悪夢のような混乱を受け継ぎました、あなたの組織でそれを使えるようにするために30日があります、そしてあなたの一日の半分は運用タスクに費やされていますか？
私はあなたがリファクタリングできると確信していますが、確かにその時間ではありません。
あなたの質問に答えるために、私はあなたが実際にそのようなデザインで良いコードを書くことができるとは思いません。技術的負債はすでに多すぎます。もし私があなただったら、私ができる機能をハッキングし、あなたがより多くの時間とあなたのチームの人々がより適切にそれに取り組むために、後日完全なリファクタリングを要求するでしょう。
リファクタリングをプッシュするように注意してください。場合によっては、上級者が製品のソースコードと所有権を購入する決定を下し、ゴミに完全にお金を浪費していると考えたくないことがあります。これは、ある仕事で私に当てはまったことです。残念ながら、マネージャーはこのようなソフトウェアの購入について決定を下し、購入するものを評価し、それが保守可能であり、大量の技術的負債があるかどうかを確認するために技術的な関与を得ることがありません。この場合、悪い決定は政治的な決定であり、リファクタリングを推進することはあなたの仕事を危険にさらす可能性があります。
費用を最大化するには、更新可能なビューを作成して、「関係」の一部を復元し、より意味のある列名を提供します。
1つの可能性は、希望する方法で構造化された（少なくともそれに近い）2番目のデータベースをセットアップし、2つのデータベース間のレプリケーションをセットアップすることです。その後、新しいデータベースに対してコードを記述し、既存のデータベース（およびアプリケーション）をそのまま残して、時間のあるときに対処することができます。
正直なところ、15日程度の作業でそれを実行できるかどうかについては、lotの疑問が残ります。特に、双方向のレプリケーションが必要かどうか（つまり、新しいアプリケーションが実際にデータを更新するか）または一方向のみか（新しいアプリケーションではデータを表示できるようにするかどうか）に依存する可能性があります。後者のケースは（もちろん）対処が劇的に簡単です。
双方向のレプリケーションが必要な場合は、作業を行うのに十分な時間がない可能性があります。特に、構造の変換を伴う双方向レプリケーションは、決して簡単なものではなく、利用可能なツールでは、サポートが不十分であることがよくあります（たとえば、双方向のすべてのデータ変換のためにすべてのSQLを手書きで書く必要がある）。
一方向のみが必要な場合は、mightが可能であるという点で適切です。それはまた、あなたがお金を使うことが許されるかどうかにかなり依存します-意図されているかなりの数のデータウェアハウスアプリケーションがあります正確におそらくこの種のタスク管理はかなり速くて簡単です-しかし、それらのほとんどはnot安いです。