0

すべてのプロジェクトで Azure Blob Storage を使用しています。プロジェクトの有効期間を通じて、Azure 内のファイルの命名規則が変更されます。コンテナーの名前を変更したり、余分なフォルダーを削除したり、その他のクリーンアップ操作を行いたい場合があります。しかし、Azure では簡単に名前を変更することはできません。コピーして削除する必要があります。

また、開発中にローカルで命名規則を変更することもできます。ただし、新しいバージョンをデプロイするときは、本番ストレージで正確な操作を行うことを覚えておく必要があります。

同時に、Entity Framework の移行を使用します。データベースを更新すると、移行スクリプトが作成されます。次に、「update-database」を実行し、DB を更新します。同じことがデプロイメント スクリプトによって自動的に実行されます。本番 DB を更新する必要があるかどうかを確認し、必要に応じて更新します。

Azure ストレージについても同様の移行の利点を実現できればよいでしょう。すべての移行スクリプトが適用されているかどうかを確認し、不足しているスクリプトのプロセスを実行します。コンテナのどこかに、最後に実行されたスクリプトへの参照が保持されます。

そのようなものは存在しますか？または、自分で何かを実装してみてください。

4

1 に答える 1

2

いいえ、そのような機能/動作は存在しません。また、EF の移行はサポートされており、データベースではなく EF 自体の一部であることを忘れないでください。したがって、Azure Blob Storage について話す場合、サービスはそのような機能を提供しないため、SQL Server 自体が提供しないのと同じです。

そのようなライブラリ/コードが存在するかどうかという質問に対して - いいえ、ありません。

しかし、あなたは非常に興味深い質問を提起しています！

私は個人的に「移住」の大ファンではありません。開発ライフサイクルの初期段階でそれを行うことができます。しかし、GA/Production になったら、何をしているのか非常に注意する必要があります。EF の移行でさえ、データベースのサイズが小さい場合は適切かもしれませんが、数百万レコードの運用データを含むテーブルを持つ DB で移行を実行する意思はありますか? ブロブと同じです。100 個または 1000 個のブロブがある場合は、問題ない可能性があります。2M ブロブはどうですか? 2M エンティティを通過し、それに対していくつかの操作を実行するコードを配置し、このコードをビルド/デプロイ プロセスの一部として実行する意思は本当にありますか? わたしは・・・しないだろう。

于 2013-09-26T06:49:31.997 に答える