インデックスを使用した変更管理のベストプラクティス

Question

私たちのITショップは、最初にDBAのグループを構築し始めています。私たち全員（私自身を含む）はアプリケーション開発/アーキテクチャの世界からやって来たので、DBAの世界はまだかなり新しいです。

DBAグループの構築に加えて、変更を移動する必要がある場合のために、変更手順とプロセス（できればベストプラクティスに基づいて）の変更を構築しようとしています。

私はそれを見つけました 次の投稿 これは、主にトリガー、ストアドプロシージャ、および/またはDDLの変更に役立ちます。ただし、必ずしもインデックスまたはベンダーデータベースに対処するわけではありません。

独自のデータベースとベンダーの両方のデータベースが混在しています。私たちの場合、一部のベンダー（すべてではありませんが）が当社と協力してデータベースとアプリケーションを構築しています。私たちは、アプリケーションが「ライブに行く」前に、アプリケーションを現在パフォーマンステストの過程にあります。したがって、インデックス（またはその欠如）をかなり重く分析しています。

私たちが作られるべきだと思うインデックスに出くわしたとき、私たち自身のデータベースとベンダーの両方について、これらに関して変化管理をどのように最もよく扱うのでしょうか？

あなたはあなたの店で何をしますか？私はプロセスについてツールについてあまり心配していません。

編集： これまでのところ、私はこの質問に対するフィードバック、コメント、答えを高く評価しています。答えのいくつかは少しツール固有であることに気付きました。それができるなら、私はもっと「不可知論的」な慣行を探しています。

ただし、不可知論者が不可能な場合は、ツールセットの場合、IBM DB2 LUW（および実際にはAIXのもの）を使用します。 WindowsにはDB2、I（IBMのI5/OS）用のDB2がありますが、ほとんどがAIX DB2です。ソースコントロール、特に転覆を使用しています。

繰り返しますが、一般的なベストプラクティスを探していますが、上記はベンダー固有のものです。

編集： 現在の決定： 推論と変更を追跡するつもりです。そのため、問題追跡ソフトウェア（私たちの場合はJira）で問題を開きます。これで、変更の優先順位、変更がどうあるべきか、変更がテストされた別の環境からの変化の結果をバックアップするデータについて、ドキュメントを追加できます。

また、SVNのスクリプトの変更を追跡することも予定しています（以下で提案したように）。これにより、どこに存在するかのバージョンを追跡できます。これは、JIRAの問題（および使用する他の監査ソフトウェア、つまり貼り付けされたリンク）に記録できます。どのような環境にどのような変化があったか、そしてその理由をより確実に知ることができます。その後、インデックスがベンダーの実装を超えて追加されたものであるか、その実装などを前に追加したものであるかどうかを追跡できます。

Answer 1

アプリケーションコードを扱うのと同じように、基本的にデータベースを扱うことを強くお勧めします。データベースをコンポーネントパーツにスクリプト化し、それらをソースコントロールに確認してから、アプリに使用する同じラベルとバージョンを使用できます。

オブジェクトをソースコントロールにするには、使用できる多くのツールがあります。 Microsoftには、Data Dudeと呼ばれるツールがあります。 Visual Studioで動作します。また、SQL Serverデータベースツール（SSDT）と呼ばれる新しいツールをリリースする準備をしています。私の会社であるRed Gate Softwareは、SQLソースコントロールと呼ばれるSSMSで動作するツールを作成します。

プロセスの観点から、私は本のいくつかの章を書きました チーム開発へのレッドゲートガイド. 。無料ダウンロードとして利用できます（または、ツリーを殺したい場合は、AmazonからPurcahseを使用できます）。開発チームのデータベースを操作することについて、さらに詳しく説明します。

Answer 2

1. バージョン制御の下で維持されているアプリケーションコードベースの一部としてデータベーススクリプトを維持します。ただし、開発と生産コードに異なる「プロセス」を使用します

2. 開発次のスクリプトを維持します。

   • base.sql-スキーマテーブルとサンプルデータを作成します
   • StagingChanges.sql-ステージング環境のためにbase.sqlに変更を加え、主に電子メールアドレス、パス、および変更される可能性のある資産
   • ProdChanges.sql-生産展開のためにbase.sqlに変更を加えます。新しいプロジェクトでは、通常、実際の生産環境でこれらをテストすることができます

3. メンテナンス

   • base.sql-生産データベースのサニタイズバージョン
   • StagingChanges.sqlおよびProdChanges.sql-上記のように
   • changerequest.sql（通常、変更要求のIDがあります）。これは、取り組んでいる現在の変更要求にスキーマ変更を適用します
   • changerequest -rollback.sql-変更要求に対して行われた変更を逆転させ、データベースを生産に戻します
   • 以前の変更要求スクリプトのアーカイブ（フォルダー）

したがって、メンテナンスモードでは、展開中にchangerequest.sqlスクリプトを生産に適用することだけです

Answer 3

データベースバージョンの制御スペースに5年間（製品管理のディレクターとして） dbmaestro）そして、20年以上にわたってDBAとして働いてきたので、Java、C＃、またはその他のファイルを扱う際にデータベースオブジェクトを扱うことができないという単純な事実を伝えることができます。

多くの理由があり、私はいくつか名前を付けます：

• ファイルは、開発者のPCと変更の変更にローカルに保存されます
  他の開発者には影響しません。同様に、開発者は同僚による変更の影響を受けません。データベースではこれはです
  （通常）ケースではなく、開発者は同じデータベースを共有しています
  環境、そのため、データベースにコミットした変更は他の人に影響します。
• 公開コードの変更は、チェックイン /送信の変更 /などを使用して行われます（使用するソース制御ツールに応じて）。その時点で、開発者のローカルディレクトリからのコードが挿入されます
  ソースコントロールリポジトリに。取得したい開発者
  最新のコードは、ソースコントロールツールからリクエストする必要があります。の
  データベース変更は既に存在し、リポジトリにチェックインされていなくても、他のデータに影響を与えます。
• ファイルのチェックイン中に、ソース制御ツールは競合チェックを実行して、地元のコピーを変更したときに同じファイルが別の開発者によって変更およびチェックインされたかどうかを確認します。繰り返しますが、データベースにこれについてはチェックがありません。あなたがあなたのローカルPCから手順を変更し、同時に私がローカルPCを形成するコードで同じ手順を変更すると、私たちは互いの変更を無効にします。
• コードのビルドプロセスは、コードのラベル /最新バージョンを空のディレクトリに取得し、ビルドを実行することによって行われます - コンパイル。出力は、既存のものをコピーして交換するバイナリです。私たちは以前に何があったかは気にしません。データベースでは、データを維持する必要があるため、データベースを再作成することはできません。また、展開はビルドプロセスで生成されたSQLスクリプトを実行します。
• SQLスクリプトを実行すると（DDL、DCL、DML（静的コンテンツの場合）コマンド）、スクリプトを作成するときに環境の現在の構造が構造と一致すると仮定します。そうでない場合は、すでに存在する新しい列を追加しようとしているため、スクリプトが失敗する可能性があります。
• SQLスクリプトをコードとして扱い、それらを手動で生成すると、構文エラー、データベース依存関係エラー、再利用できないスクリプトが発生し、維持、テストのタスクを複雑にするスクリプトを引き起こします。さらに、これらのスクリプトは、実行されるものとは異なる環境で実行される場合があります。
• バージョンコントロールリポジトリのスクリプトが、テストされたオブジェクトの構造と一致しない場合があり、生産中にエラーが発生します。

もっとたくさんありますが、あなたは写真を手に入れたと思います。

私が見つけたのは、次のことです。

1. データベースオブジェクトのチェックアウト/チェックイン操作を実施する強制バージョン制御システムを使用します。これにより、バージョン制御リポジトリは、チェックイン操作のオブジェクトのメタデータを読み取るときにチェックインされたコードと一致することを確認します。
2. ベースラインを比較の一部として利用するインパクト分析を使用して、競合を識別し、変更が（ソースコントロールリポジトリとデータベースの間のオブジェクトの構造を比較するとき）の変更が、開発または起源からの起源からの実際の変更であるかどうかを識別します。別のパスで、別のブランチや緊急修正など、スキップする必要があります。

これについて書いた記事が公開されました ここ, 、あなたはそれを読むことを歓迎します。