database - 開発者ごとに 1 つの DB かどうか?

Question

主に管理ソフトウェアを作成する企業の開発環境では、すべての開発者が独自のデータベースインスタンスを使用する必要がありますか、それとも開発中に中央のデータベースインスタンスを使用する必要がありますか? 各アプローチの長所と短所は何ですか? 他の環境や他の製品はどうですか?

score 36 · Accepted Answer

全員が同じデータベースを共有している場合、誰かがデータベースの構造を変更し、コードがデータベースと「同期」されていないと、問題が発生する可能性があります。

開発者ごとに 1 つの DB を強くお勧めします。これは、「書き込み」テストを実行して、他の誰かがすぐにオーバーライドするのを確認したくないという唯一の理由からです。簡単な例？Web サイトに製品を表示しようとしています。すべての製品が消えるまで、すべてが機能します。問題？別の開発者は、製品の「アクティブ」フラグを試して、何か他のことをテストすることにしました。そのような場合、トランザクションは機能しません。話の終わりに、他の誰かのアクションのデバッグに時間を費やします。

構造を同期するために、ステージングデータベースを開発者データベースに時々レプリケートすることを強くお勧めします (または、データベースを最初から再構築するためのツールを用意することをお勧めします)。

もちろん、データベースへの変更にはスクリプトが必要であり、すべてがソース管理にあります。

score 16 · Accepted Answer

データベース環境が不足していた時代はとっくに過ぎ去っています。私は5x15k SCSI ディスクを搭載したXW9300でこの記事を書いています。このマシンはかなり妥当な時間でかなりの ETL ジョブを実行し、(2007 年半ばの時点で) ディスクを含めて eBay で約 1,700 ポンドの費用がかかりました。開発者の観点から見ると、特にデータウェアハウジングのようなデータベース中心のプロジェクトでは、開発者と DBA の境界線はかなりあいまいです。これを書いている時点で、私は SQL Server 2005 データウェアハウス用のパーティション管理フレームワークを構築しています。

開発者は、(IMO) 次の理由から、独自の開発データベースを 1 つ以上持つ必要があります。

ストアドプロシージャ、パッチスクリプト、およびスキーマ定義ファイルをソース管理に保持する必要があります。パッチの適用は、かなりの範囲で自動化できます。Redgate SQL Compare Proなど、面倒な作業の多くを行うツールもあります。
ユーザーが自分のワークステーションに展開する必要があるため、簡単な構成管理と展開を容易にするアプリケーションアーキテクチャを推奨します。多くの展開の問題は、本番環境に到達するずっと前に解決されるか、人々が間違っていた可能性があることに気付くことさえありません。
開発者がお互いの作業でつまずくのを防ぎます。人々が ETL コードで作業しているデータウェアハウスのようなものでは、これはさらに大きなメリットです。
開発者は基本的なデータベース管理を学ばなければならないため、ある程度の責任が奨励されます。これにより、運用サポートスタッフと一部の dev-vs に対する多くの要件も解消されます。ops フリクション。
独自のデータベースがある場合、実験やその他の作業を妨げるゲートキーパーはありません。「サーバー」が存在しないため、「サーバー」の管理をめぐる政治はなくなります。これは、重要な現職の官僚機構が存在するあらゆる環境での生産性の向上です。
少量のデータの場合、通常の PC で十分高速です。Developer エディションまたはライセンスは、すべてではないにしてもほとんどのデータベース管理システムで利用でき、デスクトップ O/S で実行されます。Linux または Unix を使用している場合、これはさらに問題になりません。最大でほとんどの MIS アプリケーションを含む大容量のデータの場合、HP XW9400やLenovo D10のようなワークステーションに 5 つの 15k ディスクを装備でき、多くの専門的な開発ツールのコストよりも安く済みます。(はい、デュアルライセンスであることは知っていますが、QT の商用全プラットフォームライセンスは 1 シートあたり約 4000 ポンドです)。このようなマシンは、数千から数億行の ETL プロセスを、想像以上に高速に実行します。
これにより、スモークテストまたは調整の目的で複数の環境を簡単にセットアップできます。マシンを完全に制御できるため、本番環境で条件をモックアップするためのかなりの範囲があります。たとえば、私は一度、 Control-Mのランタイムスクリプトの一部を結合するだけで、 Control-M用の簡単なエミュレータを作成したことがあります。環境に対するこのレベルの制御と透過性があれば、かなり堅牢にテストされた展開プロセスを作成できます。これにより、本番展開で責任を追及する機会が大幅に排除されます。

小規模なチームが 14 の環境で作業しているのを見たことがありますが、ワークステーションで同時に 7 つの環境がアクティブになっていました。テーブル全体を扱う ETL などのデータベースの負荷の高い作業では、単一の開発環境で作業することは、時間の浪費や卵殻の上を歩く時間のレシピです。

また、データベースプラットフォームにシングルユーザー開発ライセンスを使用できるため、データベースライセンスだけでワークステーションのコストを節約できます。ほとんどの開発者ライセンス (Microsoft と OTN は私がよく知っている 2 つの例です) では、1 人の開発者が無料またはわずかな価格で、1 台のワークステーションでシステムを使用できます。

逆に、共有開発サーバーでのライセンス条項はしばしばやや曖昧であり、ベンダーが開発サーバーでのライセンスに関して顧客を動揺させようとしているのを何度か見てきました。

score 7 · Accepted Answer

各開発者は、完全に機能するデータベースを持っています。変更はスクリプト化され、他のコードと同様にソース管理されます。

score 5 · Accepted Answer

理想的には、はい、各開発者は「サンドボックス」開発環境を用意して、コードを共有テスト/ステージング環境にデプロイする前にテストできるようにする必要があります。

各開発者の環境では、データベースを既知の状態にリセットするスクリプトテストを実行する必要があります。これは、共有環境では実行できません。

各開発者に独自のインスタンスを提供するコストは、複数の開発者が共有環境で揮発性の変更を一緒にテストしようとすることによる混乱のコストよりも小さくなります。

一方、多くの IT ショップでは、システムは複数のアプリケーションサーバーまたは複数の物理ノードを含む複雑なインフラストラクチャを使用しています。その後、経済が変化します。人々が協力してお互いの仕事を踏まないようにするほうが、開発者ごとに複製するよりも費用がかかりません。複数の開発環境のライセンスを提供しない高価なサードパーティシステムを統合する場合は特にそうです。

したがって、答えはイエスとノーです。:-) その環境を安価に再現できる場合は、各開発者に独自の環境を提供してください。

score 4 · Accepted Answer

私の推奨事項は、2 つのレベルの開発環境を用意することです。

各開発者は、独自の dp、Web サーバーなどを備えた独自の開発システムを持っています。これにより、既知のセットアップに対してコーディングしたり、データベースやシステムを既知の状態に初期化する自動 (システムレベル) テストを記述したりできます。

開発統合環境はすべての開発者によって共有され、QA に引き渡す前に、すべてが期待どおりに連携していることを確認するために使用されます。コードはソース管理からチェックアウトされ、そこにインストールされます。任意のサーバー (db またはその他) のインスタンスは 1 つだけです。

score 3 · Accepted Answer

この質問は、開発者が自分の仕事をするために何が必要かを示唆しています。確かに、プライベートDBインスタンスを提供する必要があります。同様に重要なのは、DBが展開先と同じ製品/バージョンであることを確認することです。MySQL 6.xで開発したり、MySQL5.xにデプロイしたりしないでください。（これはアプリサーバーだけでなく、Webサーバーにも当てはまります！）

開発者DBがあるからといって、必ずしもローカルマシンでホストする必要があるとは限りません。すべての開発データベースが配置された中央のDBMSホストマシンを持つことができます。プロは、ターゲットDBに対して開発する保証人です。開発ボックスのオーバーヘッドが減り、強力なIDEとアプリサーバーのスペース/馬力が増えます。短所は、すべての開発者にとって単一障害点です。（DBMSサーバーがダウンし、誰も作業できなくなります。）DBMSのセットアップと管理に対する開発者の露出の欠如。開発者は、困難な問題を解決するために、今後のDBリリースや代替DBの選択を簡単に試すことはできません。

組織や構造によっては、長所の中には短所もあれば、その逆もあります。たぶん、開発者がDBMSを管理することを望まないでしょう。たぶん、さまざまなDBプラットフォームをサポートすることを計画しています。決定は、組織とターゲットプラットフォームの選択に要約されます。さまざまなDB/OS /アプリサーバーの組み合わせをターゲットにする場合は、各開発者が独自のDBを持っているだけでなく、一意の組み合わせで動作する必要があります。（MySQL / Tomcat / OSX for one DB2 / Jetty / Linux for another Postegres / Geronimo / WinXP for 3rdなど）一方、iSeriesでASP（アプリケーションサービスプロバイダー）タイプのショップをセットアップする場合は、もちろんおそらく、すべてのdev dbmsesを備えた中央ホストがありますが、スキーマの構造変更を可能にするために、各devには少なくとも個別のdbインスタンスが必要です。

score 1 · Accepted Answer

私の会社の私の部署には、純粋にサポートとハードウェアのコストのために、限られた開発環境しかありません。本番環境からの t-1 夜間更新に基づく環境と、静的環境がいくつかあります。

理想的には、全員が独自のものを持っている必要がありますが、多くの場合、次のことが当てはまる場合、これは非現実的です。

リソースを必要とする多数の開発者がいます (私たちの部門にはおそらく 80 人います)
各開発者は複数のリソースを必要とします (通常、私は毎日 4 ～ 5 の異なるデータベースを使用します)
最新のデータが重要です (データを十分に速く更新することはできません)

このような場合、共有インスタンスと良好なコミュニケーションが必要です。

score 1 · Accepted Answer

SQLServer Development Edition のインスタンスがローカルにインストールされています。QA DB サーバーと、複数の運用サーバーがあります。すべての開発および統合テストは、私のローカルサーバー (または他の開発者のローカルサーバー) を使用して行われます。新しいリリースは QA サーバーにステージングされます。各リリースは、お客様が承認した後、製品化されます。

私は主に Web 開発を行っているため、開発とローカルテストには VS2008 にバンドルされている Web サーバーを使用し、VM でホストされている QA Web サーバーに Web アプリを発行します。顧客に受け入れられると、アプリケーションに応じて、いくつかの異なる実稼働 Web サーバーの 1 つに公開されます。

score 0 · Accepted Answer

開発者ごとに 1 つの DB。質問なし。しかし、実際の問題は、データベース全体をどのようにスクリプト化して「データを制御」し、それらをバージョン管理するかということです。私の解決策はここにあります：http://dbsourcetools.codeplex.com/ 楽しんでください。-ネイサン。

score 0 · Accepted Answer

ここに用語の問題があると思います。DBA の帽子をかぶってからしばらく経ちました (おおおおお、ほぼ 10 年)。

各開発者が独自のサンドボックススキーマセットを持つべきであることに、誰もが同意していると思います。

MySQL および Sybase/MS SQLServer では、各データベースエンジンが複数のデータベースをサポートできます。各データベースは (通常) 他のデータベースから完全に独立しています。したがって、データベースエンジンのインスタンスを 1 つ持つことができ、各開発者にデータベーススペースを与えて、好きなように処理させることができます。唯一の問題は、開発者が tempdb を使用している場合です。そこで衝突が発生する可能性があります (これについては調べる必要があると思います)。固定データベース名を使用したクロスデータベースクエリは使用しないことに注意してください。

Oracle では、データベースエンジンのインスタンスは特定のスキーマセットに関連付けられています。同じエンジンに複数の開発者がいる場合、それらはすべて同じテーブルを指しています。この場合、はい、複数のインスタンスを実行する必要があります。

score 0 · Accepted Answer

各開発者はローカルデータベースを持っています。作成スクリプトと「標準データ」のダンプを SVN リポジトリに保存します。このテストデータに対して合格する必要があるテストの広範なセットがあります。また、標準データに共有したいデータを入れることができる「サンドボックス」データベースもあります。これは私たちにとってはうまく機能し、開発者がデータのローカルコピーを変更してテストできるようにしますが、他の開発者に渡されるものを制御します。また、スキーマの変更も厳密に管理しているため、他の誰かが言及した問題は発生しません。

score 0 · Accepted Answer

開発者ごとに 1 つのデータベースを使用する利点の 1 つは、各開発者が自分のデータのスナップショットを "既知" の状態で持っていることです。

score 0 · Accepted Answer

アプリケーションの性質に大きく依存します。分散環境のクライアント/サーバーアーキテクチャの場合は、全員が使用する中央データベースを用意するのが最善です。製品がローカルデータベースインスタンスを含む環境をユーザーに提供する場合は、それを使用できます。開発が現実世界の環境をできるだけ忠実に反映していることが最善です。

また、開発のどの段階にいるかにもよります。おそらく、初期段階では、接続、ネットワーク、および分散環境の問題に行き詰まりたくなく、ただ稼働したいだけです。このような場合、製品がある程度の成熟度に達したときに中央モデルに切り替える前に、ユーザーごとのデータベースインスタンスモデルから始めることができます。

score 0 · Accepted Answer

スキーマ変更の開発、パフォーマンステスト、特定のシナリオの設定など、開発者を隔離する必要がある場合に、ローカルバージョンを使用するというアイデアが気に入っています。

それ以外の場合は、共有バージョンを使用して、すべてが互いに同期していることを確認してください。

score 0 · Accepted Answer

データベーススキーマはソース管理に保持する必要があり、開発者はコードとデータベース用にチェックインされた変更セットを一緒に所有する必要があります。チェックインする前に、開発者は自分のデータベースで作業する必要があります。チェックイン後、自動化されたビルド (チェックイン時、夜間など) は、アプリ自体とともに中央の統合データベースを更新する必要があります。

開発者インスタンスレベルでは、読み込まれたデータは、少なくとも単体テストに適している必要があります。統合レベルでは、共有データベースはテストにも適したデータを保持する必要がありますが、本番レプリケーションに依存するべきではありません。これは、管理されたテストデータのスラック代替にすぎません。

私の経験では、開発者が共有データベースを選択する唯一の理由は、最近の実稼働データでの開発と実行が何らかの形で「現実的」であり、テストに費やす労力が少なくて済むと信じているからです。彼らは、適切なテストを作成して管理するよりも、お互いのつま先を踏んで、次の本番環境の更新の前にゆっくりと破損する共有データベースに我慢することを好みます。この種の管理手法が、IT の世界に現在のように低い評判をもたらしているのです。

score 0 · Accepted Answer

私は妥協案が好きです (すべての開発者がインフラストラクチャを共有し、誰かがスキーマの変更をテストする必要がある場合、彼らは独自の一時的な DB インスタンスを作成します (この目的のためにそこに座っているだけかもしれません))。ソース管理。）

score 0 · Accepted Answer

In my company we tend to copy the entire DB when working on non-trivial new features. The reasoning there is disk space is cheap, whereas accidental data loss (even if it's test data) isn't.

score 0 · Accepted Answer

私は両方のタイプの開発環境で働いてきました。個人的には、独自の DB/アプリサーバーを持つことを好みます。ただし、開発に共有インフラストラクチャを使用することには、いくつかの利点がある場合があります。

主なものは、共有環境が現実世界のシナリオにより似ているということです。すべての開発者が DB を共有すると、ロックやトランザクションの問題が明らかになる可能性が高くなります。各開発者に独自の DB を与えると、「自分の DB で動作する」症候群につながる可能性があります。

ただし、スキーマの変更や最適化を適用してテストする必要がある場合は、この種の設定に問題があることがわかります。

すべての開発者がインフラストラクチャを共有し、スキーマの変更をテストする必要がある場合は、独自の一時的な DB インスタンスを作成します (この目的のためにそこに座っているだけでしょうか?) 新しいものを喜んでコミットするまで。ソース管理へのスキーマ。

ソース管理にスキーマ全体 (およびテストデータ) がありますよね? 右？？？

score -1 · Accepted Answer

データベースの 1 つのインスタンスを使用することをお勧めします。データベースを動くターゲットにしたくありません。

database - 開発者ごとに 1 つの DB かどうか?

19 に答える 19

Related

Reference