開発者ごとに1つのDB

https://stackoverflow.com/questions/234580

04-07-2019
|

質問

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

解決

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

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

構造を同期するために、ステージングデータベースを開発者データベースに時々複製することを強くお勧めします（または、データベースを最初から再構築するツールを用意することをお勧めします）。

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

他のヒント

データベース環境が不足するはずの時代は過ぎ去りました。この投稿を XW9300 に5x15k SCSIディスクが含まれています。このマシンはかなり合理的な時間でかなりのETLジョブを実行し、（2007年半ばに）ディスクを含むeBayで約1,700ドルかかりました。開発者の観点から、特にデータウェアハウジングのようなデータベース中心のプロジェクトでは、開発者とDBAの間の境界線は非常に曖昧です。これを書いているとき、SQL Server 2005データウェアハウス用のパーティション管理フレームワークを構築しています。

開発者は、次の理由により（IMO）独自の1つ以上の開発データベースを持つ必要があります。

ソース管理にストアドプロシージャ、パッチスクリプト、およびスキーマ定義ファイルを保持する必要があります。パッチの適用は、かなりの程度まで自動化できます。 Redgate SQL Compare Pro などのツールもあります。このために大雑把な作業の多くを行います。
ユーザーが自分のワークステーションに展開する必要があるため、構成管理と展開を容易にするアプリケーションアーキテクチャを奨励します。多くの展開のしわは、本番環境に到達するずっと前に整理されるか、人々が間違っている可能性があることに気づきさえします。
開発者がお互いの作業につまずくのを防ぎます。 ETLコードで作業しているデータウェアハウスのようなものでは、これはさらに大きな勝利です。
開発者が基本的なデータベース管理を学ぶ必要があるため、ある程度の責任があります。これにより、運用サポートスタッフと一部の開発者向けの多くの要件もなくなります。 ops摩擦。
独自のデータベースがある場合、実験やその他の作業を妨害するゲートキーパーはいません。「サーバー」がないため、「サーバー」の管理に関する政治はなくなります。これは、既存の官僚主義が著しい環境での生産性の向上です。
小さなデータボリュームの場合、通常のPCはこれに十分高速です。開発者エディションまたはライセンスは、すべてではないにしてもほとんどのデータベース管理システムで利用でき、デスクトップO / Sで実行されます。 LinuxまたはUnixを使用している場合、これはさらに問題ではありません。ほとんどのMISアプリケーションまでの大容量データの場合、 HP XW9400 または Lenovo D10 は、プロフェッショナル開発ツーリング。（はい、デュアルライセンスであることは知っていますが、QTの商用の全プラットフォームライセンスは約4,000シートです）。このようなマシンは、予想よりも数千から数千万の行でETLプロセスを実行します。
煙のテストまたは調整の目的で、複数の環境のセットアップを容易にします。マシンを完全に制御できるため、実稼働環境で条件をモックアップするためのかなりの範囲があります。たとえば、私はかつて Control-M 用の単純なエミュレータをboで作成しました。

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

理想的には、はい、各開発者には「サンドボックス」が必要です。開発環境であるため、共有のテスト/ステージング環境にコードを展開する前でもコードをテストできます。

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

各開発者に独自のインスタンスを与えるコストは、複数の開発者が共有環境で揮発性の変化を一緒にテストしようとするために生じる混乱のコストよりも低くなります。

一方、多くのITショップでは、システムは複数のアプリケーションサーバーまたは複数の物理ノードを含む複雑なインフラストラクチャを使用しています。その後、経済が変わります。開発者ごとに複製するよりも、人々が協力して互いの作業を踏むことを避ける方が安価です。特に、複数の開発環境のライセンスを付与しない高価なサードパーティシステムを統合する場合に当てはまります。

つまり、答えはyesとnoです。 :-)環境を安価に再現できる場合は、各開発者に独自の環境を提供してください。

2つのレベルの開発環境を用意することをお勧めします：

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

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

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

開発者DBを持っていると、必ずしもローカルマシンでホストする必要があるわけではありません。すべてのdev dbが配置された中央のDBMSホストマシンを使用できます。長所は、ターゲットDBに対して開発するガランティーです。開発用ボックスのオーバーヘッドが少なく、機能的なIDEおよびアプリサーバーのスペース/馬力が増加します。短所は、すべての開発者にとって単一障害点です。（DBMSサーバーがダウンすると、だれも動作できなくなります。）DBMSのセットアップと管理に対する開発者の経験不足。開発者は、困難な問題を解決するために、今後のDBリリースや代替DBの選択肢を簡単に試すことはできません。

組織と構造に応じて、賛否両論もあります。たぶん、開発者がDBMSを管理することを望まないでしょう。さまざまなDBプラットフォームをサポートする計画があるかもしれません。決定は、組織とターゲットプラットフォームの選択に帰着します。さまざまなDB / OS /アプリサーバーの組み合わせを対象とする場合、各開発者は独自のDBを持つだけでなく、独自の組み合わせで動作する必要があります。（あるDB2 / Jetty / LinuxのMySQL / Tomcat / OSX、別のPostegres / Geronimo / WinXPの場合、3番目など）おそらく、すべてのdev dbmsを備えた中央ホストがありますが、各devには、スキーマの構造的な変更を可能にするために少なくとも個別のdbインスタンスが必要です。

ローカルにインストールされたSQLServer Development Editionのインスタンスがあります。 QA DBサーバーと複数の運用サーバーがあります。すべての開発および統合テストは、ローカルサーバー（または他の開発者のローカルサーバー）を使用して行われます。新しいリリースはQAサーバーにステージングされます。各リリースは、顧客に受け入れられた後、実稼働に入ります。

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

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

理想的には、誰もが自分のものを持っているべきですが、多くの場合、以下が当てはまる場合、これは非現実的です：

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

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

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

開発者が隔離されなければならないときにローカルバージョンを使用するというアイデアが好きです。

他の場合には、すべてが互いに同期していることを保証するために共有バージョンを使用します。

ここには用語の問題があると思います。 DBAの帽子を身に着けてからしばらく経ちました（ほぼ10年）-他の誰かが私に声をかけて修正することができます。

各開発者は独自のサンドボックススキーマを設定する必要があることに全員が同意していると思います。

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

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

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

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

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

私たちの会社では、重要な新機能を扱う際にデータベース全体をコピーする傾向があります。ディスクスペースがある理由は安価ですが、偶発的なデータ損失（テストデータであっても）はそうではありません。

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

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

ただし、スキーマの変更や最適化を適用してテストする必要がある場合は、この種のセットアップで問題が発生する可能性があります。

おそらく妥協ソリューションが最適でしょう：すべての開発者はインフラストラクチャを共有し、誰かがスキーマの変更をテストする必要がある場合、彼らが満足するまで自分の一時DBインスタンスを作成します新しいスキーマをソース管理にコミットします。

ソース管理にスキーマ全体（およびテストデータ）がありますか？そうですか

私は妥協ソリューションが好きです（すべての開発者がインフラストラクチャを共有し、誰かがスキーマの変更をテストする必要がある場合、彼らは自分の一時DBインスタンスを作成しますソース管理への新しいスキーマ。）

開発者ごとに1つのDB。質問なし。しかし、実際の問題は、データベース全体のスクリプトを作成し、「データを制御」し、それらをバージョン管理する方法です。私のソリューションはこちらです： http://dbsourcetools.codeplex.com/ 楽しむ。 -ネイサン。

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

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

私の経験では、開発者が共有データベースを選択する唯一の理由は、最近の本番データの開発と実行が何らかの形で「現実的」であり、テストにかける労力を減らすことができるということです。彼らは、適切なテストを作成して管理するよりも、お互いの足の指を踏み、共有DBを我慢して、次の実稼働のリフレッシュの前に徐々に破損することを好みます。 IT界に、現在提供している評判が悪いというのは、この種の管理慣行です。

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

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow