私のデータベースには何年にもわたって何人かのメンテナーがいますが、かつては存在していたかもしれない命名ガイドラインは無視されてきました。
ストアド プロシージャの名前を一貫した形式に変更したいと考えています。明らかに、SQL Server Management Studio 内から名前を変更できますが、Web サイトのコード ビハインド (C#/ASP.NET) で行われた呼び出しは更新されません。
コード内のすべての古いプロシージャ名を検索する以外に、すべての呼び出しが新しい名前に更新されるようにするためにできることはありますか? Visual Studio には、そのようなストアド プロシージャ名をリファクタリングする機能がありますか?
NB後者はデータベース内での名前の変更のみに関するものであるため、私の質問がこの質問の複製であるとは思いません。
段階的に変更できます。
SPROC の「根性」を新しい命名規則を満たす新しい SPROC に移動し、元の sproc を新しい SPROC に委譲するシェル/ラッパーとして残すことができます。古いラッパー SPROC がいつ呼び出されたかを追跡する「監査」テーブルを追加することもできます。 DB を使用する「あなたのアプリ」だけではありません - クロスデータベース結合や他のアプリなど)
これには小さなパフォーマンスのペナルティがあり、実際にはそれほど多くはありません (新しい SPROC をより簡単に「見つける」ことができることを除けば)
これは、少なくともアプリケーションとデータベースの 2 つの領域で処理する必要があります。他にもあるかもしれませんので、見落とさないように注意が必要です。
アプリケーション
将来のプロジェクトのための良い習慣
sproc を抽象化するのに役立ちます。私たちのアプリでは、すべての sproc を巨大なクラスにラップしています。次のような呼び出しを行うことができます。
Dim SomeData as DataTable = Sprocs.sproc_GetSomeData(5)
こうすることで、コードの最後がうまくカプセル化されます。Sprocs.sproc_GetSomeData に移動して、1 か所だけで sproc 名を微調整できます。もちろん、メソッドを右クリックして、シンボリックな名前変更を実行して、メソッド呼び出しをソリューション全体で修正できます。
抽象化なしで
その抽象化がなければ、sproc 名に対してファイル内検索 (Cntl+Shift+F) を実行するだけで、結果が正しい場合は、ファイルを開いてすべての出現箇所を検索/置換できます。
SQL サーバー
ビューの依存関係を信用しない
SQL サーバー側では、理論的には MSSMS 2008 で sproc を右クリックして [依存関係の表示] を選択できます。データベース内でsprocが使用されているすべての場所のリストが表示されるはずですが、この機能に対する私の信頼は非常に低いです。SQL 2008 では改善されているかもしれませんが、以前のバージョンでは明らかに問題がありました。
依存関係の表示は私を傷つけました。それが癒されるまでには時間がかかります。:)
包んでください！
しばらくの間、古い sproc を保持する必要があります。これが、sproc の名前変更がこのようなプロジェクトである主な理由です。最終的に完了するまでに 1 か月かかる場合があります。
最初にその内容を同じパラメーターで新しい sproc を呼び出す単純な TSQL に置き換え、ログを作成して、しばらくすると古い sproc が実際に使用されていないかどうかを確認できるようにします。
最後に、古い sproc が使用されていないことを確認したら、それを削除します。
他の場所？
他にもたくさんのエリアがあるかもしれません。Reporting Services が思い浮かびます。SSIS パッケージ。古い sproc を保持し、新しいものに再ルーティングする手法 (上記) を使用すると、何かを見逃したかどうかを知るのに役立ちますが、何を見逃したかはわかりません。これは多くの痛みにつながる可能性があります！
幸運を！
残念ながら、ソース コードやその他のデータベース オブジェクトを検索するのは少し面倒です。
SSIS パッケージ、SQL エージェント ジョブ、Reporting Services rdl、およびメインのアプリケーション コードを忘れないでください。
spProc1|spProc2正規表現を使用したファイルの検索をサポートするツールがあれば、ソース コード内のすべてのオブジェクト名を同時に検索するような正規表現を使用できます(過去に RegexBuddy を使用しました)。
奇妙なものを見逃した可能性をカバーしたい場合は、以前のすべてのストアド プロシージャを 1 か月間残しておき、それらにカスタム SQL トレース イベントとAPP_NAME(), SUSER_NAME()役立つと思われるその他の情報をログに記録させてから、改名版。次に、このイベントを監視するトレースを設定します。
アプリケーションのすべてのパスをテストして、データベースへの呼び出しと関連するストアド プロシージャが更新されていることを確認することはできません。
グローバルな検索と置換を使用して (ただし、提案された各置換を確認してください)、インスタンスが失われないようにします。アプリが適切に構造化されている場合、各ストアド プロシージャが呼び出される場所は 1 つだけにする必要があります。
アプリケーションを変更する限り、すべてのストアド プロシージャを web.config ファイルの設定として保持しているため、すべての名前が 1 か所にあり、データベースへの変更に合わせていつでも変更できます。
アプリケーションがストアド プロシージャを呼び出す必要がある場合、名前は web.config から決定されます。
これにより、アプリケーションがデータベース サービス層に対して行う可能性のあるすべての呼び出しを簡単に管理できます。
DB、ストアドプロシージャなどへの接続を使用する場合は、これらのメソッドを委任するサービスクラスを作成する必要があります。
このように、データベースやSPなどの何かが変更された場合、サービスクラスを更新するだけで、すべてが破損することから保護されます。
リファクタリングやリシャーパーなど、名前の変更を管理できるVS用のツールがあります
SSMS の依存関係は動的な SQL 参照またはデータベース外の参照を取得しないため、次を使用してプロシージャへの参照のリストを取得します。
SELECT OBJECT_NAME(m.object_id), m.*
FROM SYS.SQL_MODULES m
WHERE m.definition LIKE N'%my_sproc_name%'
並行して開発することにはリスクもあります。
私はこれを行い、SQL プロセスを呼び出す SQL プロシージャを見つけるために、ストアド プロシージャ名と SQL ディガーのソース コード内のグローバル検索に大きく依存しました。
SQL Server (SQL 2000 以降) は自身の依存関係をほとんど理解していないため、スクリプトのテキストを検索して依存関係を見つけなければなりません。依存関係は、他のストアド プロシージャまたは動的 SQL の部分文字列である可能性があります。
私はあらゆる種類のコードをリファクタリングすることに賛成です。
ここで本当に必要なのは、ストアド プロシージャの名前をゆっくりと段階的に変更する方法です。
私は確かにグローバルな検索と置換を行いません。
むしろ、機能の小さな部分を特定し、プロシージャ間の関係を理解するにつれて、小さな部分をリファクタリングできます。
ただし、このプロセスの基本は、データベースのソース コード管理です。
データベースへの変更を通常のコードと同じように管理しないと、深刻な問題が発生します。
DBSourceTools を見てください。http://dbsourcetools.codeplex.com
これは、開発者がデータベースをソース コード管理下に置くのに役立つように特別に設計されています。
リファクタリングの前に、データベースを特定の状態に復元する反復可能な方法が必要です。
次に、リファクタリングした変更を制御された方法で再適用します。
この考え方を受け入れると、この巨大でエラーが発生しやすいタスクが簡単になります。
これは、SQL Server 2005 以降を使用していることを前提としています。以前に使用したオプションは、古いデータベース オブジェクトの名前を変更し、古い名前で SQL Server シノニムを作成することです。これにより、選択した規則に合わせてオブジェクトを更新し、コードや SSIS パッケージなどの参照を適宜置き換えることができます。次に、選択したメンテナンス リリースに応じて、コード内の参照を徐々に更新することに集中できます (一度にすべてを壊すのではなく)。すべての参照が見つかったと感じたら、コードが QA に進むときにシノニムを削除できます。
FileSeekなどのユーティリティを使用して、プロジェクト フォルダー内のすべてのファイル内の内容を検索します。Windows の検索を信用しないでください。速度が遅く、ユーザーフレンドリーではありません。
そのため、OldSprocOneという名前のストアド プロシージャがあり、その名前を SP_NewONe に変更したい場合は、出現するすべてのOldSprocOneを検索 してから、出現するすべてのOldSprocOneを検索し て、その名前が他の場所でまだ使用されていないかどうか、問題が発生しないかどうかを確認します。次に、コード内のすべての出現箇所の名前を変更します。
これは、大規模なシステムでは非常に時間がかかり、反復する場合があります。
プロシージャの名前を無視し、レガシー DAL を Enterprise Library Data Access Block 5 に置き換えることについて、より懸念があります。
Enterprise Library 5 DAAB のデータベース アクセサー - Database.ExecuteSprocAccessor
次のようなコードを持つ
public Contact FetchById(int id)
{
return _database.ExecuteSprocAccessor<Contact>
("FetchContactById", id).SingleOrDefault();
}
特に現在のコードが DataTables または DataSets ::shudders: を通過する場合、一貫した名前を持つストアド プロシージャを使用するよりも、少なくとも 10 億倍の価値があります。