9

SQL Server を使用したデータ中心のアプリケーションがあります。それが展開される環境は私たちの管理下になく、そこには DBA がいません (彼らはすべて中小企業です)。そのため、各アプリケーション/データベースの更新の配布プロセスを可能な限り自動化する必要があります。

アプリケーションのバージョン間の通常の変更 (予測できない場合があります) に加えて、各バージョンで新しいシード データを配布する必要があることは既にわかっています。このシード データは、システム内の他のデータに関連する場合があります。たとえば、v2 から v3 への更新プロセス中に一部のマスター データの 2 つの新しい行を挿入し、v5 から v6 への更新プロセス中に他の 5 行を挿入する必要があるかもしれません。

EF

Entity Framework Db Migrations (4.3.1 リリース以降の Code-First のない既存のデータベースで利用可能) を確認しました。これは、従来のシーケンシャル スクリプトをより自動化され制御された方法 (Fluent Migrations など) で表します。

SSDT

一方、別の考え方で、SSDT とその dacpacs、スナップショット、デプロイ前後のスクリプトを確認しました。

質問は次のとおりです。

  1. これらの技術/哲学のうち、説明されているケースにより適切なものはどれですか?

  2. 他に使用できるテクノロジー/哲学はありますか?

  3. 他にアドバイスはありますか？

前もって感謝します。

4

2 に答える 2

3

それは興味深い質問です。ここ Red Gate では、シンプルな展開パッケージを提供する方法について多くの顧客から問い合わせを受けているため、今年後半にこの問題に取り組みたいと考えています。基本的に SQL スクリプトを exe にラップするSQL Packagerがあります。

dacpacs は、あなたが説明したユース ケースをカバーするように設計されていると言えます。ただし、私が理解している限り、ターゲットに適用されたときに展開スクリプトを動的に生成しています。欠点は、事前にテストされた SQL スクリプトを展開するときに得られるような、あたたかみのあるあいまいな感覚が得られないことです。

以前に dacpacs でデータを更新しようとしたことがないので、これがどの程度うまく機能するか知りたいです。私が思い出す限り、それはターゲットテーブルを切り捨て、それらを再作成します。

私は EF 移行の経験がないので、このトピックに関する回答を読んでみたいと思います。

于 2012-04-26T14:53:51.337 に答える
1

おそらくハイブリッドソリューションを採用するでしょう。展開パッケージャーのアイデアを放棄したくはありませんが、その一方で、アプリケーションの性質 (最終ユーザーとしての中小企業、DBA なし、アップグレードの義務がないため、複数の「有効な」データベース バージョンが共存している) により、スキーマとデータを含む移行プロセスの完全な制御を放棄することもできません。私たちの場合、EF 移行のような完全な移行には、展開前および展開後のスクリプトでは不十分な場合があります (または、少なくとも快適ではありません)。シード データの追加/削除、「1 対多」から「多対多」への関係の変更、または根本的なデータベース スキーマの変更 (したがって、以前にリリースされたスキーマからこのスキーマへのデータ移行) などの変更は、当社の一部である可能性があります。私たちの最初のバージョンがリリースされたときの日記作品。

したがって、バージョン リリースごとに「アップ」および「ダウン」システムを備えた EF 移行を使用することになるでしょう。原則として、各「アップ」は最後のデータベース スナップショット (および各ダウン、その前のスナップショット) で dacpac を呼び出し、それぞれがこの特定の移行のための独自の展開パラメーターを持ちます。EF の移行では、バージョニング ラインが処理されますが、データ移行の複雑な部分も処理される可能性があります。

このハイブリッドな方法で、より安全だと感じます。Dacpacs の方法でバージョニング ライン コントロールを見逃していたのと同じくらい、Entity Framework Migrations での自動化とスキーマ変更の検出を見逃していました。

于 2012-04-27T08:24:47.390 に答える