8

私が継承した現在のプロジェクトは、主に 1 つの正規化されていないテーブルを中心に展開しています。正規化の試みがいくつかありますが、必要な制約が設定されていません。

例: Project テーブルには、(他の値の中でも) クライアント名があり、クライアント名だけを含むクライアント テーブルもあります [どこにもキーはありません]。client テーブルは、新しいプロジェクトを追加するときにユーザーに提供する値のプールとしてのみ使用されます。クライアント テーブルまたは外部キーに主キーがありません。

このような「設計パターン」は、データベースの現在の状態とそれを使用するアプリケーションで一般的です。私が自由に使えるツールは、SQL Server 2005、SQL Server Management Studio、および Visual Studio 2008 です。私の最初のアプローチは、正規化が必要な情報を手動で判断し、Select INTO クエリを実行することでした。ケースバイケースよりも優れたアプローチはありますか、それとも自動化できますか?

編集: また、「作業指示書番号」は IDENTITY (autonumber、unique) フィールドではなく、順番に生成され、各作業指示書に固有であることを発見しました。既存の番号付けにもいくつかのギャップがありますが、すべてが一意です。移行前にダミー行を生成するためのストア プロシージャを作成するための最良の方法はありますか?

4

7 に答える 7

10

使用可能な設計に移行するための最良のアプローチは？気をつけて

現在データベースを使用しているすべてのアプリケーションを壊す（そして修正する）意思がない限り、既存の構造をあまり変更できないため、選択肢は限られています。

始める前に、動機について慎重に考えてください。既存の問題（修正するバグ、作成する拡張機能）がある場合は、ゆっくりと進んでください。ただし、他の誰も気付かないような改善を達成するためだけに、稼働中の本番システムをいじくり回すことはめったに価値がありません。これはあなたに有利に働く可能性があることに注意してください-既存の問題がある場合、問題を修正するための最も費用効果の高い方法はこの方法でデータベース構造を変更することであると経営陣に指摘することができます。これは、変更に対する管理サポートがあることを意味します-そして（うまくいけば）何かが洋ナシの形に変わった場合のそれらのバックアップ。

いくつかの実用的な考え...

一度に1つの変更を行います...そして1つの変更のみ。先に進む前に、各変更が正しいことを確認してください。「2回測定し、1回カットする」という古いことわざが関係しています。

Automate Automate Automate ... SQL Server Management Studioを使用して、本番システムに「ライブ」で変更を加えないでください。変更全体を一度に実行するSQLスクリプトを作成します。これらを開発し、データベースのコピーに対してテストして、正しく取得できることを確認します。テストサーバーとして本番環境を使用しないでください。本番環境に対して誤ってスクリプトを実行する可能性があります。専用のテストサーバーを使用します（データベースのサイズが4G未満の場合は、独自のボックスで実行されているSQL Server Expressを使用します）。

バックアップ...スクリプトの最初のステップは、データベースをバックアップすることです。これにより、問題が発生した場合に戻ることができます。

ドキュメント...誰かが12か月以内にあなたのところに来て、アプリケーションの機能Xが壊れている理由を尋ねた場合、診断と修復を支援するためにデータベースに加えられた正確な変更の履歴が必要になります。最初の良いステップは、すべての変更スクリプトを保持することです。

キー...通常、データベース内で、アプリケーションから公開されないように、主キーと外部キーを抽象化しておくことをお勧めします。ビジネスレベルでキーのように見えるもの（作業指示番号など）には、例外があるという不穏な習慣があります。キーを適切な制約のある追加の列として導入しますが、既存の列の定義は変更しないでください。

幸運を！

于 2009-03-21T21:07:42.823 に答える
1
  1. 構造化する必要があると思われる方法で新しいデータベースを作成します。
  2. 「oldId」や「errorDesc」などの列を使用して、新しいデータベースにimportErrorテーブルを作成します
  3. 古い構造から行を選択して新しい構造に挿入しようとする、単純で手続き型の読みやすいスクリプトを作成します。挿入が失敗した場合は、可能な限り具体的なエラーをimportErrorテーブルに記録します（具体的には、挿入が失敗した理由）。
  4. スクリプトを実行します。
  5. 新しいデータを検証します。importErrorテーブルに記録されたエラーがあるかどうかを確認します。データが無効であるかエラーがある場合は、スクリプトをリファクタリングして再実行し、必要に応じて新しいデータベース構造を変更する可能性があります。
  6. 確実な変換スクリプトが得られるまで、手順1〜5を繰り返します。

このプロセスの結果、次のようになります。a）古い構造に対して検証され、「実用主義」に対してテストされた新しいdb構造。b）コーディングが必要になる可能性のある潜在的な問題のログ（スキーマに不要な譲歩が必要なために変換で修正できないエラーなど）

（たとえば、SQLではなく、選択したスクリプト/プログラミング言語でスクリプトを作成すると便利な場合があります。）

于 2009-03-21T21:04:43.563 に答える
0

これを自動化する賢明な方法を考えることはできません。出力を有用なものにしたい場合は、このようなリファクタリングでは人間の入力が重要です。

作業指示番号をやり直してください。これを引き続きIDENTITY列にしたい場合。おそらくデータを入力し、最大のものを見つけてから、ALTER TABLEを使用してIDENTITYにすることができますか？手元にあるTSQLツールがないため、残念ながらテストできません。または、自然キーと考えてください。

于 2009-03-21T20:56:15.533 に答える
0

現在のアプリケーション インターフェイスを維持する必要があるかどうか、またはアプリケーション内のクエリを書き直す予定があるかどうかについては言及されていません。

いずれにせよ、私は

  • 新しいスキーマを設計する
  • 必要に応じてカーソルを使用して T-SQL バッチを作成し、データを移行する

カーソルは、操作クエリの最初の選択肢ではありませんが、非常に構造化された方法でタスクを実行できるため、このタイプのアプリケーションには最適です。これらのスクリプトは非常に読みやすい傾向があります。これは、すぐには機能せず、数回繰り返した場合に重要です。

于 2009-03-21T22:11:49.767 に答える
0

SQL Server 2005 の一部である SQL Server Integration Services (SSIS) を使用して、移行を支援できます。あるフォームから別のフォームにデータを転送するために使用されます。

http://en.wikipedia.org/wiki/SQL_Server_Integration_Services http://www.microsoft.com/sqlserver/2005/en/us/integration-services.aspx

于 2009-03-21T22:12:29.237 に答える
0

ストアド プロシージャを使用して変換プロセスを支援することをお勧めします。

具体的には：

  1. コードで使用されているクエリをストアド プロシージャに 1 つずつ置き換えます。置き換えの一環として、ストアド プロシージャに対して直接ユニット (または統合) テストを記述します。StoredProcsそこにデータベース アクセスを統合するためのコード レベルのヘルパー クラスを検討してください。
  2. すべてのクエリが sproc になったら、これらの単体テストを使用してデータベースをリファクタリングし、期待される動作を変更していないことを確認できます。
  3. 追加の利点: 将来の破損を防ぐために、これらの単体テストを使用できます。
于 2009-03-21T21:21:52.883 に答える
0

簡単なヒントを追加するだけです。エンティティ関係図を A4 または A3 の 1 枚で目の前に持っている場合、適切な正規化は多対多の関係を意味しません。この本、または少なくともサイトもチェックしてください。

于 2009-05-15T19:58:34.877 に答える