SQL Server対応サービスの開発標準？

Question

私は、SQL Server Reporting Services、Analysis Services、およびIntegration Servicesの開発に関するベストプラクティスを見つけようとしています。

誰もがこのテーマに役立つリンクやガイダンスを持っていますか？

Answer 1

私はSSISとしか話せませんが、いくつかは他のものにも当てはまります。

パッケージをファイルとして保存し、ソース管理に入れます。

可能であれば、サーバー間で変更されたり実行されたりするものに変数を使用します。

設定ファイルを使用して、異なる環境の設定を保存します。

外部ソースからのデータを処理するときは、警告なしでフォーマットが変更されることを前提としています（つまり、各カラムに必要なデータがあることを確認してください） （あるいは、DTSで一度私たちに起こったように、社会保障番号はその人にどれくらい支払うか言ったフィールドに入っていました。

新しい列の追加、プロセスに不可欠な列の削除、列の順序の並べ替え（特に、ファイル自体に列名がない場合は悪い）、列のタイトルは同じままです（姓のデータがFirst_nameという名前の列にあって、その逆の場合はファイルを取得するとはいです）、システムの値と一致しない新しい値を持つデータ（私は思っています電子メールフィールドのメモ、この形式の名前のような奇妙なデータをフラットアウトするlastname - 'Willams、Jo' first_name - 'hn'（全体の名前を取得するために2つのフィールドを結合する - 明らかに彼らのデータ入力の人々は、名前がどこにあってもスペースを使い果たし、次のフィールドで続けていた！）。

汚れていないデータをデータベースに保存しないでください。

処理または送信するファイルのコピーは、常に保管してください。驚くほど頻繁に調査する必要があります。

フィールドの問題が原因でプロセスが失敗した場合は、クリーニングが必要なエラーとログレコードをログに記録します。 1つのレコードに余分なスペースがあったために、2千万レコードのファイルが失われたことを知るよりも、テーブルのエラーを見るほうがはるかに簡単です。その中にどれがあるのか​​把握しようとする。

SSISで同様のインポートを行う場合は、すべての標準ログとデータを持つテンプレートプロジェクトを作成します。テンプレートから開始し、作業中の新しいファイルに基づいて新しいマッピングに調整し、すべてのSSISパッケージを最初から書き直すよりも、そのファイルに固有のものをマイナーなものにする方がずっと速いです。

メタデータを格納します。遅かれ早かれ、ファイルが受信された後、どれくらいの頻度で失敗したか、またはどれくらいの間、インポートが実行されたか、最後にインポートされたかが尋ねられます。私たちのすべてのパカッハは、メタデータテーブルに開始時刻と終了時刻を格納するタスクを開始して終了します。すべての失敗パスには、メタデータでインポートが失敗したとマークするタスクが含まれています。最終的に、新しいファイルが大幅にオフになっている場合に、予想されるレコードの数を知り、失敗するシステムを構築することができます。メタデータは、あなたが期待していたファイル全体ではなく、部分ファイルをいつ送信したかを識別し、実際にまだ必要な30万の販売目標を吹き飛ばすのを防ぐのに役立つレコード数などを保存するためにも使用できます。