開発者はLocalDBと「開発」インスタンスの使用を許可する必要がありますか？

Question

以前にここに投稿された「開発者が本番データベースにクエリを実行できるようにする必要がありますか？」という質問の要領によく似ています。

多くの企業は、開発者が開発マシンにSQL Server Expressなどをインストールするのを防ぎ、代わりに集中開発SQL Serverの使用を促進しています。

具体的には、次のことを確実にするために行われます。

開発サーバーとプロダクション間のパッチレベルの一貫性
上記のパッチを証明および検証する機能
データセキュリティ;開発サーバー上のデータのみが開発に使用されます
回復性;データは回復可能であり、まだバックアップされています
本番環境に移行すると問題が発生する可能性がある照合順序の違い

私にとって、これらの引数はすべておそらく無効ですが、パッチの引数は例外です。しかし、ローカルマシン上のデータベースがテストではなく開発アクティビティにのみ使用されている場合、アプリケーションがテスト/ UATなどを介して本番環境に進んだときにパッチが適用されることが証明されます。

照合順序は有効な理由ではないようです。これがデータベースの問題であるかのように、作成時に設定する必要があります。 SharePointとSCCMは、私の知る限り、これに関して問題があります;）

ここで、それが開発専用であり、データベースが本番環境に「移動」されず、唯一の移動は次のようになると想定します。

本番環境へのデプロイ用に生成されるデータベースを作成したスクリプト
「本番」サードパーティシステムからのバックアップは、検証と開発に適した場所で復元および切り捨てられます

誰でも何か問題を見ることができますか？何か不足していますか？

最大の懸念の1つは、ローカルのdbインスタンスが古くなってしまうことですが、これはソフトウェア管理の問題であり、DBAのIMOではありません。

Troy Witthoeft · Accepted Answer

はい。すべての開発者には、SQL Serverのローカルインスタンスと共有SQL Serverインスタンスが必要です。それらは異なる目的のために存在します。両方が必要です。

おそらく、現在の環境は次のようになりますか？

上記のように、何人かの開発者が変更を作成し、それらを共同のSQL Developerデータベースに展開しています。これは悪いです。 Microsoft MVP Troy Huntは、この時代遅れのアプローチの問題点をいくつか文書化しています here 。主なものは...

適切なソース管理ができない。 BIG！
サーバーレベルの権限がないとパフォーマンスを調整できない。
他人に影響を与えずに実験できない。

このパターンは、開発者の競合を引き起こします。競合の症状の1つは、データベースの無秩序な増加です。多くのデータベースは、開発者が作業を行うための安全で隔離されたスペースを探すときに作成されます。組織がこのパターンにしがみついている理由はいくつかあります。 1つ目は、適切なソース管理システムに投資していないことです。もう1つは、このデザインパターンを継承しているだけで、変更する必要がないことです。マイクロソフトは、このパターンから着実に前進し、このようなものへと進んでいます...

上の図では、各開発者がVisual Studioを使用して、データベースの変更をSQL Serverのローカルインスタンスに書き込み、保存しています。これらのローカル変更は、適切なソース管理システムに同期されます。ここで、各開発者は、自分の変更がチェックインされるまで他の人に影響を与えない環境で設計および実験できます。そしてその時、対立は解決されるでしょう。

上記で使用されているローカルデータベースは、LocalDB、Express、またはDeveloperのエディションです。 Simple-Talkは、それぞれの長所と短所を比較検討するのに非常に役立ちますここ。マイクロソフトがローカル開発データベース用に非常に多くの選択肢を作成したのには理由があります：LocalDB、Express、Developer..。

選択する必要がある場合、すべての開発者がローカルバージョンSQL Server Developerエディションがインストールされていると主張するのは難しいことではありません。これは完全に無料で、Enterpriseエディションと機能的に同等です。これにより、チーム全体がMicrosoft BIスタック全体（SQL Server、SSIS、SSRS、およびSSAS）内を安全な方法で探索および設計できるようになります。

共同データベースは引き続き保持できますが、開発用ではなく、テスト用でなければなりません。システムレベルの設定が本番環境と同期しているサーバーです。ハードウェア、OS、パッチなど.

Cody Konior · Answer

私にとってこれらすべての議論は特に無効です

OK。しかし、彼らは私たちの残りのものではありません。どうして？

開発サーバーとプロダクション間のパッチレベルの一貫性

アプリケーションがテストを通過したときにパッチが適用されることが証明されます

パッチを適用すると、安定性とデータ破損の問題を修正できます。それは関係なく開発マシンで行われるべきです。

データセキュリティ;開発サーバー上のデータのみが開発に使用されます

「あるべきもの」と「あるべきもの」を区別すると便利です。開発者は、データベースに機密データ（必ずしもPIIである必要はありませんが、どちらも無料ではありません）を取得します。それが起こります。

回復性;データは回復可能であり、まだバックアップされています

超重要です。

本番環境に移行すると問題が発生する可能性がある照合順序の違い

SharePointとSCCMのみがこの問題を抱えています

一時テーブルを使用するものには、この問題があります。それは非常に一般的です。ほとんどの人はそもそも標準的な照合を行うため、それに気付くことはありません。

開発専用であり、データベースが本番環境に「移動」されないと想定

なぜそれを想定するのでしょうか？多くの場合、開発から本番に移行します。他にどのようにして初めて初めて製品を実装しますか？純粋なスクリプト？必ずしもアプリケーションがしばらくの間プリプロダクション状態であった場合とは限りません。

最大の懸念の1つは、ローカルDBインスタンスが古くなってしまうことですが、これはソフトウェア管理の問題であり、DBAのIMOではありません。

あなたは単にあなたが何をして何をサポートしていないのか、そしてその理由について声明を発表する必要があります。

LocalDBは現在SSDTの中核部分であり、不可避です。ただし、リモートからアクセスすることはできず、スケジューリングコンポーネントもありません（Expressにも同様の問題があります）。したがって、バックアップ、メンテナンス、および整合性チェックに関して、DBAは一般にそれをサポートしていません。

ただし、一元化された開発サーバーに統合することには意味があります。そして今、Developer Editionは無料であり、より多くのものを正当化することはさらに簡単です。

Solomon Rutzky · Answer

概念的に言えば、あなたは正しい軌道に乗っています。成熟した開発プロセス/ソースコード管理、継続的インテグレーション（CI）、自動テスト、、およびを含むITグループを含むソフトウェア開発ライフサイクル（SDLC）を持つ組織の場合さまざまな環境とワークステーションを管理して、ソフトウェアとパッチレベルに関して同期を保つ方法、、規律のある開発者、a）プロセスに従う、b）連携する、c）作業ITでは、そして50（またはいくつでも）開発DBが機能します。

はい、一貫したソフトウェアとパッチレベルを任意の数のワークステーションで維持できます。
はい、「問題」は自動テストやQA/UAT環境で表面化する可能性があります。
多くの開発DBはバックアップが簡単ではありませんが、不可能ではありません。ローミングプロファイルを使用している場合は、各Windowsユーザーの「ローカル設定」フォルダーにあるデータファイルをバックアップする方が簡単な場合があります。または、少なくとも、ITがすべての開発ワークステーションからファイルを取得するようにスクリプト化することができます。

しかし、他のほとんどすべてと同様に、それは本当に状況のコンテキストに帰着します。

個別の開発DBを持つことの1つの利点は、さまざまなプロジェクトを互いに影響を与えることなく同時に処理できることです。（もちろん、これが唯一の利点かもしれません。）

ただし、考慮すべきさまざまな問題があります。

チームの規模と、特定のプロジェクトに何人の人が取り組んでいますか？プロジェクトで作業する人が増えるほど、すべての変更をすべての人が受けられるように、共有/集中型開発サーバーが必要になります。
照合順序 SQL Server Express LocalDB には、特に厄介なニュアンス/制限/制限があります。

LocalDBのインスタンス照合はSQL_Latin1_General_CP1_CI_ASに設定されており、変更できません。データベースレベル、列レベル、および式レベルの照合は通常サポートされています。包含データベースは、メタデータと包含データベース照合で定義されたtempdb照合規則に従います。

インスタンスレベルの照合順序は、tempdb（つまり、dbスコープのオブジェクト名解決、一時テーブルのデフォルトの照合順序であり、テーブル変数ではない）だけでなく、ローカル変数名のカーソル名/パラメーター名、およびgotoラベル名。したがって、運用サーバーにSQL_Latin1_General_CP1_CI_AS以外のインスタンスレベルの照合順序がある場合、LocalDBは適切な選択ではありません。
Enterprise Edition機能を使用していますか？オンラインインデックスの再構築を行うだけの場合は、おそらくそれは問題ではありません。ただし、テーブルパーティション分割などを使用している場合、LocalDBは適切な選択ではありません。
おそらく最大の問題は、バグにつながる可能性のある環境の差異（OSレベル、ソフトウェアパッチレベル、インスタンス構成、DB構成など）から生じる潜在的な問題の全体的な範囲の拡大です。自動テスト/ QA/UATがこれらの問題を検出することを（一般的な意味で）すでに受け入れていますが、これは保証されません！人間は間違いを犯し、allをテストするallコードパスとallを考え出す必要があることを考えると= /// =）all（---）データのバリエーション（タイプ、サイズなど）は、任意の数のシナリオがテストされない可能性が高く、バグはそれを通り抜け、顧客が本番環境でそれを見つけるまで気付かれない可能性があります。いずれにしてもこれは起こりますが、LocalDBを使用する場合は可能性が高まるため、各開発者は独自のプライベートDBを持つことができます。

それが実際に下るのは、チーム環境でそれを使用する説得力のある理由は何ですか？さまざまな仕事で、私は常にアプリ開発者とデータベースエンジニアがいるグループで働いていました。アプリ開発者は、実行速度を上げるためだけにストアドプロシージャをモックアップすることがありましたが（DBEでは不十分）、DBEはほとんどの作業を行いましたアプリ開発者が書いたコードのチェック（つまり修正）を含むDBプログラミング。 LocalDBを使用すると、グループでの作業がはるかに困難になります。また、SQL Server Express（またはDeveloper Edition）を使用して、リモートでアクセスできる各開発ワークステーションに個人用インスタンスを作成し（共同作業を容易にします）、そのレベルの分離を必要とすることはまれでした。あるプロジェクトのDBの変更が別のプロジェクトに悪影響を与える。

もちろん、データベースエンジニア（DBE）であった私たちには、Express EditionまたはDeveloper Edition、あるいはその両方のローカルインストールがありました。ただし、これは、インスタンスレベルの構成やセキュリティなど、共有サーバーで許可されている以上の制御を必要とするテストを行うためのものです。また、ローカルインスタンスを時々使用しましたが、それほど頻繁ではありませんでした。しかし、私の個人的なプロジェクトでは、私はLocalDBをlove愛しており、それをかなり頻繁に使用しています。