9

DBAを使用せずに多くの（10人以上の）開発者間でデータベースの変更を維持および同期するという問題に他の人がどのように取り組んでいるかについて興味がありますか？基本的に、誰かがデータベースに変更を加えたい場合、それを行うためのいくつかの戦略は何ですか？（つまり、「車」モデルを作成したので、適切なDDLをデータベースなどに適用したいと思います。）

私たちは主にPythonショップであり、ORMはSQLAlchemyです。以前は、ORMを使用してモデルを作成するような方法でモデルを作成していましたが、最近、次の理由でこれを廃止しました。

  • ORMを使用して変更を追跡できませんでした
  • ORMの状態がデータベースと同期していませんでした（たとえば、主にインデックスと一意の制約に関連する多くの違い）
  • 開発者がチームへの電子メールを介してデータベースの変更を文書化しない限り、データベースの変更を監査する方法はありませんでした。

この問題に対する私たちの解決策は、基本的に、データベースへのすべての変更をチェックし、受け入れられたすべてのデータベース変更をaccepted_db_changes.sqlファイルに適用する「ゲートキーパー」個人を配置することでした。これにより、データベース変更を行う必要がある開発者は、要求をproposed_db_changes.sqlファイルに入れます。このファイルをチェックインし、更新されると、開発マシン上の個人データベースに変更を適用します。モデルにインデックスや制約を作成するのではなく、データベースに明示的に適用します。

データベーススキーマを維持するためのいくつかの戦略とは何か、そして私たちの戦略が合理的であると思われるかどうかを知りたいです。

ありがとう！

4

4 に答える 4

2

解決策はむしろ管理的であり、技術的です:)

一般的なルールは簡単で、プロジェクトにはツリーのような依存関係のみが存在する必要があります。-バージョン管理にプロジェクトソースコードと一緒に保存されたスキーマの単一のマスターソースが常に存在する必要があります-マスターの変更によって影響を受けるすべてソースはマスターソースが更新されるたびに自動的に再生成される必要があります。手動による介入は許可されません。自動生成が機能しない場合は、マスターソースまたはジェネレーターを修正し、ソースコードを手動で更新しないでください。すべての再生成はマスターソースを更新したのと同じ人が実行し、マスターソースの変更を含むすべての変更を単一のトランザクションと見なす必要があります（単一のソース管理コミット、DBの更新を含むすべての影響を受ける環境に対する単一のビルド/展開）

強制されると、これにより100％信頼できる結果が得られます。

マスターソースには基本的に3つの選択肢があります。1）DBメタデータ、ライブDBに接続するツールによるDB更新後にソースが生成されます。2）ソースコード、特定のツールがソースからSQLスキームを生成し、特別な方法で注釈が付けられます。次に、SQLがDBで実行されます。3）DDL、SQLスキーマとソースコードの両方が何らかのツールによって生成されます。4）他の説明が使用されます（たとえば、SQLスキーマとソースコードの両方を生成する特別なPerlスクリプトによって読み取られたテキストファイル）

1,2,3も同様に優れています。必要なツールが存在し、高価ではない場合4は普遍的なアプローチですが、プロジェクトの最初から適用する必要があり、数千行のコードのオーバーヘッドがあります。維持する奇妙な言語

于 2010-05-04T19:02:50.140 に答える
1

それで、あなたが物理データベース上で直接データベースを設計していると仮定するのは正しいですか？私は何年も前にこれを行っていましたが、結果のデータベースの品質はかなり悪かったです。モデリングツールを使用する場合（個人的にはSybase pdesignerが最適だと思いますが、周りを見回してください）、誰でもモデルに変更を加え、必要に応じてローカルデータベースを同期できます（ドキュメントタスクも取得します）。したがって、bobahの投稿では、マスターは物理データベースではなくpdesignerモデルです。

あなたのaccepted_db_changes.sqlファイルは変更スクリプトの膨大なリストの1つですか？ファイル名などを変更するというアイデアが好きかどうかはわかりません。2つのdbバージョンの違いは、変更スクリプトの順次リストであるため、次のようなモデルはどうでしょうか。

Ver1 (folder)
  Change 1-1.sql
  Change 1-2.sql
  Change 1-3.sql
Ver2 (folder)
  Change 2-1.sql
  Change 2-2.sql
  Change 2-3.sql

コミットする前に、各変更（新しいファイル）が確認される場所。

一般的なルールは、開発環境で可能な限り多くのdbデプロイメントを自動化するように意識的に努力することです。この作業で、かなりのROIを達成しました。redgateなどのツールを使用してddlを生成できます（APIがありますが、SQLAlchemyで動作するかどうかはわかりません）。IMO、DBの変更は簡単なはずです。ブロックされていることに気付いた場合は、自動化できるものを確認してください。

于 2010-05-05T10:17:03.173 に答える
1

SQLalchemy Migrateツールを試しましたか？

これらは、データベース設計の変更を自動移行するように特別に設計されています。

于 2010-05-01T16:00:22.977 に答える
1

データベースのリファクタリングの方法だけでなく、データベースを管理するための一般的な戦略が含まれているため、「データベースのリファクタリング」という本が役立つ場合があります。

彼のシステムは、すべての開発者がデータベースの独自のコピーと、本番環境にデプロイする前に使用されるいくつかの一般的なテストデータベースを持っていることを期待しています。あなたの状況は、データベースを使用する個別のアプリケーションが多数ないため、本で説明されているより簡単な状況の1つです（ただし、データベースの移行を説明する方法を知っている人が必要です）。最大のことは、データベースに変更を加えるだけでなく、ソース管理の情報からデータベースを構築し、小さな移行（@WoLpHの回答を参照）によって変更を記述できるようにすることです。また、少なくともORM <->データベーステストを実行して、それらがまだ同期していることを確認すると、作業が簡単になります。

于 2010-05-06T23:07:50.123 に答える