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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

超重要です。

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

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

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

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

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

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

あなたは単にあなたがしていることとサポートしていないこととその理由についての声明を出す必要があります。

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

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

概念的に言えば、あなたは正しい軌道に乗っています。成熟した開発プロセス/ソースコード管理、継続的インテグレーション（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データベーススコープのオブジェクト名の解決、一時テーブルのデフォルトの照合順序だけでなく、テーブル変数にも影響を与えるだけでなく、ローカル変数名のカーソル名/パラメータ名、gotoラベル名にも影響します。したがって、SQL_Latin1_General_CP1_CI_AS運用サーバーに以外のインスタンスレベルの照合順序がある場合、LocalDBは適切な選択ではありません。

• Enterprise Editionの機能を使用していますか？オンラインインデックスの再構築を行うだけの場合は、おそらくそれは問題ではありません。ただし、テーブルパーティション分割などを使用している場合、LocalDBは適切な選択ではありません。

• おそらく最大の問題は、バグの原因となる可能性のある環境の違い（OSレベル、ソフトウェアパッチレベル、インスタンス構成、DB構成など）から生じる潜在的な問題の全体的な範囲の拡大です。自動テスト/ QA / UATがこれらの問題を検出することを（一般的な意味で）既に受け入れていますが、これは保証されません！人間はミスを犯すと、人間が思い付くする必要があることをことを考えると、すべてチェックしますテストのすべてのコード・パスとすべてのデータ（種類、サイズなど）のバリエーションを、それは可能性が高いシナリオの任意の数ということですありませんテストされ、バグはそれを通り抜け、顧客が本番環境でそれを見つけるまで気付かれないかもしれません。これはとにかく発生しますが、LocalDBを使用する場合は可能性が高まるため、各開発者は独自のプライベートDBを持つことができます。

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

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