62

私は、既存の小さなプロジェクトに 2012 データベース プロジェクトを採用しようとしている研究段階にあります。私は C# 開発者であり、DBA ではないため、ベスト プラクティスについては特に詳しくありません。私は数時間グーグルとスタックオーバーフローを検索してきましたが、いくつかの重要な展開シナリオを適切に処理する方法がまだわかりません.

1) いくつかの開発サイクルの過程で、データベースの複数のバージョンをどのように管理しますか? データベースの v3 にクライアントがあり、それらを v8 にアップグレードしたい場合、どうすればこれを管理できますか? 私たちは現在、製品のすべてのバージョンについて、手作りのスキーマとデータ移行スクリプトを管理しています。これを個別に行う必要がありますか、それとも新しいパラダイムにこれをサポートまたは置き換えるものがありますか?

2) データを移動する必要があるような方法でスキーマが変更された場合、これを処理する最善の方法は何ですか? データを保存するために配置前スクリプトで何らかの作業が行われ、配置後スクリプトがデータを適切な場所に戻すと仮定します。それがその方法ですか、それとももっと良いものがありますか？

3) これらの新しいテクノロジをどのように使用するのが最善かについて、その他のアドバイスやガイダンスも大歓迎です!

更新:最初にこの質問をして以来、問題に対する理解が少し深まりました。実行可能な解決策を思いついたものの、それは私が望んでいた解決策ではありませんでした。これが私の問題の言い換えです：

私が抱えている問題は、純粋にデータ関連です。アプリケーションのバージョン 1 を使用しているクライアントをアプリケーションのバージョン 5 にアップグレードしたい場合、データベースにデータがなくても問題はありません。SSDT にインテリジェントにスキーマを比較させ、データベースを 1 回で移行させるだけです。残念ながら、クライアントにはデータがあるため、それほど単純ではありません。アプリケーションのバージョン 1 からバージョン 2、バージョン 3 (など) へのスキーマの変更はすべてデータに影響します。現在のデータ管理戦略では、バージョン アップグレード (1 から 2、2 から 3 など) ごとにスクリプトを維持する必要があります。これにより、アプリケーションのバージョン 1 からバージョン 5 に直接移行することができなくなります。そこに直接移行するためのデータ移行スクリプトがないためです。クライアントごとにカスタム アップグレード スクリプトを作成したり、アップグレード スクリプトを管理してすべてのバージョンからすべての上位バージョンに移行したりすることは、指数関数的に困難です。私が望んでいたのは、SSDT が可能にするある種の戦略があり、それによって物事のデータ側をより簡単に、おそらくスキーマ側と同じくらい簡単に管理できるようになることでした。私の最近の SSDT の経験では、そのような戦略が存在するという希望はありませんでしたが、別の方法で見つけたいと思っています。

4

4 に答える 4

9

この件に関してこれ以上有用な情報は見つかりませんでしたが、ツールを知り、いじったり遊んだりするのに時間を費やしました。私の質問に対する受け入れられる答えをいくつか思いついたと思います。これらは必ずしも最良の答えではありません。これらのシナリオをより適切にサポートするためのメカニズムやベスト プラクティスが他にあるかどうかはまだわかりませんが、思いついたのは次のとおりです。

特定のバージョンのデータベースの配置前および配置後スクリプトは、以前のバージョンからデータを移行するためにのみ使用されます。すべての開発サイクルの開始時に、スクリプトは一掃され、開発が進むにつれて、以前のバージョンから新しいバージョンにデータを安全に移行するために必要な SQL で肉付けされます。ここでの 1 つの例外は、データベース内の静的データです。このデータは設計時に認識され、T-SQL MERGE ステートメントの形式で配置後スクリプトに永続的に存在します。これにより、最新のパブリッシュ スクリプトだけを使用して、任意のバージョンのデータベースを新しい環境にデプロイできるようになります。すべての開発サイクルの最後に、以前のバージョンから新しいバージョンへの発行スクリプトが生成されます。このスクリプトには、スキーマを移行するために生成された SQL と、手作りのデプロイ スクリプトが含まれます。はい、公開ツールをデータベースに対して直接使用できることは知っていますが、それはクライアントにとって良い選択肢ではありません。dacpac ファイルも認識していますが、それらの使用方法がよくわかりません。生成されたパブリッシュ スクリプトは、私が知っている運用環境のアップグレードに最適なオプションのようです。

だから私のシナリオに答えるために：

1) データベースを v3 から v8 にアップグレードするには、生成されたパブリッシュ スクリプトを v4、v5、v6 の順に実行する必要があります。これは、現在行っている方法と非常によく似ています。それはよく理解されており、データベース プロジェクトにより、これらのスクリプトの作成/保守がはるかに簡単になるようです。

2) スキーマがデータの下から変更されると、デプロイ前およびデプロイ後のスクリプトを使用して、新しいバージョンに必要な場所にデータを移行します。影響を受けるデータは基本的に、配置前スクリプトでバックアップされ、配置後スクリプトで元の場所に戻されます。

3) これらのシナリオやその他のシナリオでこれらのツールを使用する最善の方法について、引き続きアドバイスを求めています。ここで何か問題が発生した場合、または他に注意すべき問題がある場合は、お知らせください。ありがとう！

于 2013-03-14T19:28:31.397 に答える
3

これまでのところ、このスレッドは素晴らしいものでした。

私はまったく同じ懸念に取り組んでおり、かなり大規模なレガシーアプリケーションで、組織でこの問題に取り組もうとしています。(TFS ブランチで) SSDT に移行するプロセスを開始しましたが、展開プロセス、カスタム移行の管理、および参照/検索データを途中で本当に理解する必要がある時点に来ています。

さらに複雑なことに、私たちのアプリケーションは 1 つのコードベースですが、「顧客」ごとにカスタマイズできるため、この 1 つのプロジェクトで約 190 のデータベースを扱っています。おそらく通常の 3 つほどではありません。私たちは常に展開を行っており、かなり頻繁に新しい顧客を設定しています. 私たちは現在、古い学校の増分リリース スクリプト (およびそのバージョンで新しい顧客を作成するための関連スクリプト) を備えた PowerShell に大きく依存しています。これをすべて理解したら貢献する予定ですが、他に学んだことは何でも共有してください. 最終的にはバージョンごとにカスタム リリース スクリプトを維持することになると思いますが、それはわかります。プロジェクト内の各スクリプトを維持し、From および To SqlCmd 変数を含めるというアイデアは非常に興味深いものです。そうすれば、おそらく途中で剪定するでしょうが、

ところで-補足-無駄を最小限に抑えるというトピックについては、列の適切な命名/データ型規則の適用を自動化する方法、およびすべての主キーと外部キーの自動生成をベースにする方法を見つけるのにも多くの時間を費やしました。命名規則、インデックスおよびチェック制約などについて。最も困難な部分は、ルールに従わない「逸脱者」に対処することでした。誰かが興味を持っている場合は、いつかそれも共有するかもしれませんが、今のところ、この展開、移行、および参照データのストーリーを重点的に追求する必要があります. 再度、感謝します。あなたたちは私の頭の中で今朝探していたものを正確に話していたようです.

于 2013-05-17T12:53:52.057 に答える