3

また、テスト環境と本番環境の間でそれらをどのように同期させますか？

データベーステーブルのインデックスに関しては、データベースをクエリするコードを作成する上で不可欠な部分であるというのが私の哲学です。インデックスへの影響を分析せずに、新しいクエリを導入したり、クエリを変更したりすることはできません。

そのため、すべての環境間でインデックスの同期を維持するために最善を尽くしていますが、正直なところ、これを自動化することはあまりうまくいっていません。これは一種の無計画な手動プロセスです。

定期的にインデックスの統計を確認し、不要なインデックスを削除します。私は通常、削除スクリプトを作成して、それを他の環境にコピーして戻すことでこれを行います。

しかし、あちこちでインデックスが作成され、通常のプロセスの外で削除され、違いがどこにあるかを確認するのは非常に困難です。

私が本当に役立つことの1つは、次のような単純な数値のインデックス名を使用することです。

idx_t_01
idx_t_02

ここで、tはテーブルの短い省略形です。関係するすべての列を巧みに利用しようとすると、インデックスのメンテナンスが不可能になります。

idx_c1_c2_c5_c9_c3_c11_5

そのようなインデックスを区別するのは難しすぎます。

インデックス管理をソース管理と開発ライフサイクルに統合するための本当に良い方法を持っている人はいますか？

4

9 に答える 9

11

インデックスはデータベース スキーマの一部であるため、他のすべてのものと一緒にソース管理する必要があります。通常の QA およびリリース プロセス (特にパフォーマンス テスト) を経ずに、運用環境でインデックスを作成する必要はありません。

スキーマのバージョン管理については、他にも多数のスレッドがありました。

于 2008-09-30T13:24:12.727 に答える
6

データベースの完全なスキーマは、コードのすぐ横にあるソース管理にある必要があります。「完全なスキーマ」とは、テーブル定義、クエリ、ストアド プロシージャ、インデックスなど、すべてを意味します。

新規インストールを行う場合は、次のことを行います。 - 製品のバージョン X をチェックアウトします。- チェックアウトの「データベース」ディレクトリから、データベース スクリプトを実行してデータベースを作成します。- チェックアウトのコードベースを使用して、データベースとやり取りします。

開発中は、すべての開発者が自分のプライベート データベース インスタンスに対して作業する必要があります。スキーマを変更するときは、改訂されたコードベースに対して機能する一連の新しいスキーマ定義ファイルをチェックインします。

このアプローチでは、コードベースとデータベースの同期の問題が発生することはありません。

于 2008-09-30T13:25:09.807 に答える
5

はい、 DMLまたはDDL の変更はすべてスクリプト化され、ソース管理にチェックインされます。ほとんどの場合、レールでのアクティブ レコードの移行によって行われます。Rails の警笛を鳴らし続けるのは嫌いですが、DB ベースのシステムを長年構築してきた中で、移行ルートは、私が使用または構築した自作システムよりもはるかに優れていることがわかりました。

ただし、私はすべてのインデックスに名前を付けています (DBMS が選んだクレイジーな名前を考え出させないでください)。それらにプレフィックスを付けないでください、それはばかげています（sysobjectsまたはあなたが持っているデータベースにタイプメタデータがあるため）が、テーブル名と列、たとえばtablename_col1_col2を含めます。

そうすれば、sysobjects をブラウズしている場合、特定のテーブルのインデックスを簡単に確認できます (また、これは習慣の力でもあります。昔、私が使用したいくつかの dBMS では、インデックス名は DB 全体で一意だったので、唯一の方法は固有の名前を使用するようにします)。

于 2008-09-30T13:22:41.407 に答える
1

ここには2つの問題があると思います。インデックスの命名規則と、ソース管理/ライフサイクルへのデータベースの変更の追加です。後者の問題に取り組みます。

私は長い間Javaプログラマーでしたが、最近、システムの一部のデータベースアクセスにRubyonRailsを使用するシステムが紹介されました。RoRについて私が気に入っていることの1つは、「移行」の概念です。基本的に、001_add_foo_table.rb、002_add_bar_table.rb、003_add_blah_column_to_foo.rbなどのようなファイルでいっぱいのディレクトリがあります。これらのRubyソースファイルは、「up」および「down」と呼ばれるメソッドをオーバーライドして、親クラスを拡張します。「up」メソッドには、以前のバージョンのデータベーススキーマを現在のバージョンにするために行う必要のある一連のデータベース変更が含まれています。同様に、「down」メソッドは変更を前のバージョンに戻します。特定のバージョンのスキーマを設定する場合は、

開発プロセスのこの部分を作成するために、これらをソース管理にチェックインし、味わうために味付けすることができます。

ここでは、Railsについて特別なことは何もありません。ただ、この手法が広く使用されているのを初めて見ただけです。おそらく、001_UP_add_foo_table.sqlと001_DOWN_remove_foo_table.sqlのようなSQLDDLファイルのペアも使用できます。残りはシェルスクリプトの小さな問題であり、読者に残された演習です。

于 2008-09-30T13:30:55.100 に答える
0

現在のプロジェクトでは、ソース管理に2つのものがあります。空のデータベースの完全ダンプ（pg_dump -cを使用して、テーブルとインデックスを作成するためのすべてのddlが含まれる）と、データベースのバージョンを決定するスクリプトです。そして、変更/ドロップ/追加を適用して、現在のバージョンにします。前者は、新しいサイトにインストールするとき、およびQAが新しいテストラウンドを開始するときに実行され、後者はアップグレードのたびに実行されます。データベースを変更するときは、これらのファイルの両方を更新する必要があります。

于 2008-09-30T13:32:34.457 に答える
0

grailsアプリを使用すると、ドメインオブジェクトを表すファイル内でインデックス定義を定義しているため、インデックスはデフォルトでソース管理に保存されます。参考までに「Grails」の視点を提供するだけです。

于 2008-09-30T13:32:48.887 に答える
0

ソース管理ではなく、インデックスの作成スクリプトにインデックスを配置します。;-)

索引の命名:

  • テーブル「customer」のフィールド「name」の IX_CUSTOMER_NAME
  • 主キーの PK_CUSTOMER_ID、
  • UI_CUSTOMER_GUID、一意の顧客の GUID フィールド (したがって、"UI" - 一意のインデックス)。
于 2008-09-30T13:24:25.007 に答える
0

私は常に SQL のソース管理 (DDL、DML など) を行っています。そのコードは他のものと同じです。その良い習慣。

于 2008-09-30T13:25:17.110 に答える
0

データサイズが異なるため、インデックスが異なる環境間で同じであるべきかどうかはわかりません。テスト環境と本番環境にまったく同じデータがない限り、インデックスは異なります。

それらがソース管理に属しているかどうかについては、よくわかりません。

于 2008-09-30T13:26:03.237 に答える