恐ろしく設計されたデータベースの上に良いコードを書く希望はありますか？

これが私の苦境です。私が最近継承したいくつかのプログラムの1つは、バックエンドに恐ろしいデータベースで構築されています。尊敬されているクリエイターは、どうやらリレーショナルコンセプトを高く評価していなかったようです。一意のクライアントIDとして名前が付けられた、すべてのクライアントのテーブル。83の暗号化された名前のフィールド。コードはすべて手続き型であり、多数のインラインSQLステートメントが連結されています。

同じデータベースから実行される重要な補助アプリケーションが提供されなかったため、私はそれをゼロから再作成するという任務を負っていました。私は唯一の開発者であり、少なくとも半分の時間は運用に費やされているため、私の第一の責任でもありません。これから30日間の避けられない期限が設定されます。

私は経験が浅いにも関わらず、このデータベースと既存のアプリケーションを以前よりもはるかに良く設計できたと確信していますが、データベースを変更し、既存のアプリケーションを調整し、私がそうしなかったことを確認するのは現実的ではないと思います追加のアプリケーションをこれほど迅速に作成する必要がある間、何も壊しません。

だから私はひどいデータベースにこだわっていると仮定しましょう。このような悪い構造で作業する必要がある場合、それに準拠するものを書くと、何かが完全に壊れたり新しい機能が必要になるまで技術的な負債が山積みになってしまいますか？どうすればこの状況にアプローチし、うまくいけば機能するアプリケーション以外に何か良いものを得ることができますか？

編集：誰かが興味を持っている場合、この恐ろしいデータベースとそれを実行したアプリケーションを廃棄することになりました。補助的なアプリケーションの作成を外部委託しました（私はこの設定には関与していませんでした）が最終的に2人の異なる請負業者に委託されました。私は、今日もまだ使用されている3日間で、部分的に機能する恐ろしい修正のハックを急いで行かなければならなくなりました。

希望はありますが、特にデータベースの設計が恐ろしいことに誰も気付いていない場合、それは困難な戦いです。アブストラクションレイヤーを使用して、厄介さを取り除こうとすることもできますが、戦いに値しない可能性があります。

私のアドバイスは、データベース自体に十分な抽象化を作成して、アプリケーション自体がクリーンで適切に設計されるようにすることです。その方法は、場合、あなたが今までにデータベースを修正することができ、それはデータベースを設計したかを気にしないため、アプリケーションが影響を受けることはありません。

これは、所定の場所にあるデータベースを扱うときに通常使用するアプローチであり、ほとんどの場合、ゼロ思考で設計されています。いくつかのサービス層がゲートウェイ/リポジトリと通信するリポジトリまたはゲートウェイパターンのいくつかの選択アプリケーションは、貧弱な設計の隔離に役立ちます。

すべてのDBを処理するインターフェイスレイヤーを構築し、それとインターフェイスするアプリを作成します。データベースが「修正」された場合は、「インターフェース」を交換/更新するだけです。このアプローチにより、不良なデータベースや、他のアプリケーションにフィードを提供していて混乱させられないデータベースを処理する際の時間を大幅に節約できました。

痛い...あなたは悪夢のような混乱を引き継いで、あなたの組織でそれを使えるようにするために30日があり、あなたの半日は運用タスクに費やされていますか？

リファクタリングできると確信していますが、確かにその時間内ではありません。

あなたの質問に答えるために、私はあなたが実際にそのようなデザインで良いコードを書くことができるとは思わない。技術的な負債はすでに多すぎます。もし私があなただったら、私ができる機能をハックし、後日、チームにより多くの時間と人々が対応できるようになったら、完全なリファクタリングを押します。

リファクタリングに注意してプッシュしてください。上級者が製品のソースコードと所有権を購入する決定を下すこともありますが、彼らは完全にゴミにお金を浪費しているとは思わないでしょう。これは、私が持っていたある仕事で私に当てはまりました。残念ながら、マネージャーはこのようなソフトウェアの購入を決定しますが、購入するものを評価するために技術的な関与を得ることはありません。この場合、悪い決定は政治的なものであり、リファクタリングを推進することはあなたの仕事を危険にさらす可能性があります。

データベースは、他のコードと同様にリファクタリングできます。テストを記述および記述する必要があるコードの影響を受ける部分を修正して、他に何も破損しないことを確認します。他のリファクタリングと同じように、一度に少しずつ実行します。データベースのリファクタリングに関する優れた本があり、混乱のクリーンアップを始めるのに役立つかもしれません。 http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

他にもありますが、私は個人的にこの記事のテクニックを読み、それを使って作業しました。

また、ビューを作成して、クエリを簡単にする構造に厄介な変換作業を行うことで、データベースのクエリに必要な方法を再構築できることを忘れないでください。

予算に見合うだけの価値を得るには、更新可能なビューを作成して、「関係」の一部を復元し、より意味のある列名を提供します。

可能性の1つは、構造化された（少なくともそれに近い）2番目のデータベースをセットアップし、2つのデータベース間のレプリケーションをセットアップすることです。その後、新しいデータベースに対してコードを記述し、既存のデータベース（およびアプリケーション）をそのまま残し、時間があるときに対処できるようにします。

正直なところ、15日以内の仕事でそれができるかどうかは、まだ多くの疑問を抱いています。特に、双方向のレプリケーション（つまり、新しいアプリケーションが実際にデータを更新する）が必要なのか、一方向（新しいアプリケーションがデータを表示できるようにする）のみに依存する可能性があります。後者のケースは（もちろん）対処が劇的に簡単です。

双方向のレプリケーションが必要な場合は、ジョブを実行するのに十分な時間ではない可能性があります。特に、構造の実質的な変換を伴う双方向レプリケーションは決して些細なことではなく、利用可能なツールはしばしばそれを非常に貧弱にサポートします（たとえば、両方向のすべてのデータ変換のためにすべてのSQLを手書きする必要があります）。

片道だけが必要な場合は、可能になると境界を接する可能性があります。また、あなたがお金を費やすことを許可しているかどうかにかなり依存します-のために意図されているアプリケーション倉庫かなりの数のデータがあり、正確に、おそらくそれはかなり迅速かつ容易になるだろうタスクのこの種は、管理する-しかし、それらのほとんどは安くはありません。