database - 古いデータベーススキーマのリファクタリングに関するヒント

Question

データモデルを反映しなくなった従来のデータベーススキーマにとらわれていることは、すべての開発者にとって悪夢です。しかし、保守性のためにコードをリファクタリングするという話が飛び交っていますが、古いデータベーススキーマをリファクタリングするという話はあまり聞いたことがありません。

古いスキーマに依存するすべてのコードを壊すことなく、より良いスキーマに移行する方法に関するヒントは何ですか? 私は自分の要点を説明するために特定の問題を提案しますが、役立つことが証明されている他のテクニックについても気軽にアドバイスしてください。それらも役立つ可能性があります。

私の例：

私の会社は製品を受け取り、発送します。現在、製品の受領書と製品の出荷には、いくつかの非常に異なるデータが関連付けられているため、元のデータベース設計者は、受領書と出荷用に別のテーブルを作成しました。

このシステムを使って 1 年が経ちましたが、現在のスキーマはあまり意味がないことに気づきました。結局のところ、受け取りも発送も基本的には取引であり、それぞれ商品の金額を変更する必要があり、基本的には +/- 記号だけが異なります。実際、一定期間にわたって製品が変更された合計量を見つける必要があることがよくありますが、この設計では非常に扱いにくい問題です。

明らかに適切な設計は、ID が ReceiptInfo または ShipmentInfo テーブルのいずれかの外部キーである単一の Transactions テーブルを持つことです。残念なことに、間違ったスキーマが既に数年間運用されており、数百のストアドプロシージャと、そこから書き出された数千行のコードが含まれています。では、スキーマを正しく機能するように移行するにはどうすればよいでしょうか?

score 5 · Accepted Answer

データベースのリファクタリングのカタログ全体を次に示します。

http://databaserefactoring.com/

score 3 · Accepted Answer

これを回避するのは非常に困難です。データベースをリファクタリングした後のいくつかの簡単なオプションは次のとおりです。

元のスキーマに一致するビューを作成しますが、新しいスキーマからプルします。ビューの更新を処理できるように、ここでトリガーが必要になる場合があります。

新しいスキーマを作成し、両側にトリガーを配置して、反対側を維持します。

score 3 · Accepted Answer

この本 (データベースのリファクタリング)は、インベントリデータベースでほぼ同じ問題に対処しなければならなかったときを含め、レガシーデータベーススキーマを扱うときに私にとって天からの贈り物でした。

また、データベーススキーマへの変更を追跡するシステム (ソースコントロールリポジトリに格納されている一連の変更スクリプトなど) を用意しておくと、コードとデータベースの依存関係を把握するのに非常に役立ちます。

score 1 · Accepted Answer

ここでは、ストアドプロシージャとビューが役に立ちます。システムがそれらを使用しない場合でも、それらを使用するように変更してから、その下のデータベースをリファクタリングします。

その後、領収書と出荷がビューになります。

注意してください、領収書と出荷は、私が扱ったほとんどのシステムで実際には2つの非常に異なる獣です. 領収書はサプライヤーにリンクされ、出荷は顧客 (または顧客/出荷先の場所) にリンクされます。在庫レベルでは、それらはしばしば同じように表されます。

score 0 · Accepted Answer

場合によっては、より優れた構造を持つ新しいテーブルを作成してから、古いテーブルの名前を使用してビューを作成できますが、新しいテーブルのデータに基づいています。そうすれば、より良い構造に移行し始める間、コードが壊れることはありません。ただし、非リレーショナルテーブルから複数のレコードを持つリレーショナル構造に移動する場合もありますが、コードは 1 つしか想定していません。これは、サブクエリを使用する開発者がいる場合に特に当てはまります。

次に、それぞれが変更されると、ビューから実際のテーブルに移動します。最終的には、ビューを削除できます。これにより、少なくとも、物事を動かしながら段階的に作業を続けることができますが、より良い設計を使用するために物事を修正し始めることができます.

score 0 · Accepted Answer

すべてのデータアクセスはストアドプロシージャに限定されていますか? そうでない場合、タスクはほぼ不可能になる可能性があります。その場合は、データ移行スクリプトが古いスキーマから新しいスキーマにうまく移行することを確認し、ストアドプロシージャが入力と出力を尊重することを確認する必要があります。

うまくいけば、それらのどれにも「select *」クエリはありません。その場合は、'sp_help tablename' を使用して列の完全なリストを取得し、それをコピーして、各 * を完全な列リストに置き換えます。これは、クライアントコードを壊さないようにするためです。

徐々に変更を加え、多くの統合テストを行うことをお勧めします。いくつかのバグを導入せずに大幅な改造を行うことは困難です。

score 0 · Accepted Answer

最初に、テーブルスキーマを作成します。Enterprise Architect を使用して、レガシーデータベースに対して既にそれを行いました。DB を選択すると、すべてのテーブル/フィールドが作成されます。次に、すべてをカテゴリに分割する必要があります。すべての商品の受け取りと発送をまとめて例に挙げます。クライアントのものは別のカテゴリに分類されます。すべてが明確になると、新しいテーブル、新しいリリース、および新しいフィールドを作成して、フィールドをリファクタリングできるようになります。もちろん、すべてがストアドプロシージャなしでアクセスされる場合、これには多くの変更が必要になります。

score 0 · Accepted Answer

トランザクションテーブルの ID が ReceiptInfo または ShipmentInfo のいずれかへの外部キーであることは明らかではないと思います。逆に考えてみてください。オブジェクト指向モデルでは、トランザクションテーブルが必要であり、ReceiptInfo または ShipmentInfo にはトランザクションテーブルへの外部キーが必要です。運が良ければ、ReceiptInfo または ShipmentInfo で新しいレコードが作成されるコード内のポイントは 1 つか 2 つだけです。そこで、Transaction テーブルにエントリを追加するコードを追加し、その後、Transaction への外部キーを使用して ReceiptInfo または ShipmentInfo にエントリを作成する必要があります。

database - 古いデータベース スキーマのリファクタリングに関するヒント

8 に答える 8

Related

Reference

database - 古いデータベーススキーマのリファクタリングに関するヒント