非常に大規模なデータ セットを毎月処理する一連の大規模で複雑なストアド プロシージャを継承しようとしています。
VB6 で書かれた元のプロセスと一致するように、それらをデバッグ中です。t-sql で書き直すことにした理由は、vb プロセスに数日かかり、この新しいプロセスに数時間かかるためです。
これですべて問題ありませんが、これらの大量の t-sql コードのチャンク (1.5k 行以上) をリモートで読み取り可能/保守可能にするにはどうすればよいでしょうか。
t-sql をあまり頭が痛くならないようにした経験があれば大歓迎です。
まず、.sqlファイルでいっぱいのディレクトリを作成し、そこで維持します。この.sqlファイルのセットをリビジョン管理システムに追加します。SVNはうまく機能します。これらをデータベースにロードし、既存のものを上書きするツールを用意します。
テストデータベースと、月次処理の出力がどのようになるかを示すベースラインレポートを用意します。テストは、バージョン管理下の.sqlファイルの形式でもある必要があります。
これで、procを好きなだけリファクタリングし、後でテストを実行して正しい機能を確認できます。
SQL の書式設定/整形については、 http: //www.sqlinform.com/ で成功しました。無料のオンライン バージョンを試すことができ、デスクトップ バージョンも利用できます。
SQLinForm は、すべての主要なデータベース (ORACLE、SQL Server、DB2/UDB、Sybase、Informix、PostgreSQL、MySQL など) 用の自動 SQL コード フォーマッタであり、多くの書式設定オプションがあります。
ApexSQLScript は、データベース全体をスクリプト化するための優れたツールです。その後、それをソース管理にチェックインし、変更を管理できます。
また、sproc を一貫して文書化すると、sys.sql_modules のソース コードに関するデータを使用してそれらに関する情報を引き出すことができることもわかりました。タグなどを使用して、サブシステムの文書化に役立てることができます。
また、スキーマ (または複数のデータベース) を使用してください。これは、データベースを論理ユニットに分割し、アーキテクチャの問題を指摘するのに非常に役立ちます。
大きなコードに関して言えば、SQL2005 の CTE 機能が、多数のネストされたクエリ (再帰的でない) を含むコードを管理するのに非常に役立つことが最近わかりました。一連のネストとインデントを管理する代わりに、CTE を宣言して構築し、最終ステートメントで使用できます。これは、冗長なネストされたクエリと列を削除する方がはるかに簡単に見えるため、リファクタリングにも役立ちます。
ストアド プロシージャと UDF は、大規模なコード ベースを管理し、ダーク コーナーを排除するために不可欠です。ビューはパラメーター化できないため、ビューがそれほど役立つとは思いませんでした (結果セットが小さい場合、これらのケースで UDF を使用できます)。
間違いなくコード、特にインデントを再フォーマットすることから始めてください。
次に、SQL をモジュール化します。チャンクを、独自のスタンドアロン ファイル内の、より小さな、わかりやすい名前のプロシージャと関数に引き出します。これだけでも、大きな SQL ファイルの理解を深める上で非常にうまく機能することがわかりました。
SQLを可能な限りモジュール化して、必要に応じて機能を維持、リファクタリング、追加できるようにする一連のテストを用意してください。私はかつて、合計5000行のストアドプロシージャを継承することができましたが、それでも悪夢があります。プロジェクトが終了したら、その過程でXツリーを破壊する笑いのためにストアドプロシージャを印刷しました。私たちの会社の1つの毎週のスタンドアップセッション中に、私はそれを端から端までレイアウトし、それは建物の全長を伸ばしました。これは、ストアドプロシージャを作成および保守しない方法の例として使用されます。
実行できることの1つは、ソース管理へのすべての変更を保存する自動スクリプトを使用して、手順の変更を確認できるようにすることです（以前のバージョンと現在のバージョンの差分を使用）
もちろん無料ではありませんが、T-SQL を一貫した方法でフォーマットしておくには、Redgate Software のSQL Promptが非常に便利です。proc の構文が正しい限り、いくつかのキーストローク (Ctrl+K、Y) で即座に再フォーマットされます。オプションを使用すると、SQL のフォーマット方法を細かく制御できます。