8

[関連する質問を dba.stackexchange に投稿しましたが、ほとんど回答が得られなかったので、ここに投稿しようと思いました。]

MSDN ドキュメントは統合失調症です。公式のSQL Server ドキュメントでは、「ソリューション、プロジェクト、およびアイテム」の使用は非推奨であると言われています。警告バナーには、

「この機能は、Microsoft SQL Server の将来のバージョンでは削除される予定です。新しい開発作業でこの機能を使用することは避け、現在この機能を使用しているアプリケーションを変更することを計画してください。」

ただし、MSDN docs の他の場所では、プロジェクトとソリューションを使用することが、スクリプトなどを保存するための規定の方法です。

では、データベース アプリケーションを構成するさまざまなスクリプト、クエリ、およびファイルを格納およびパッケージ化するために、何をお勧めしますか? また、現在の仕事でソリューションまたはプロジェクトのフレームワークを実際に使用している人がいるかどうか、またそれらを何に使用しているかについても知りたいです。

[注: この機能に VS2010 を使用できることは認識していますが、チームの他のメンバーは VS にアクセスできないため (また、この質問への回答に記載されている理由により) 、SSMS ベースのアプローチにのみ関心があります。 .]

チーム内で SQL ステートメントとクエリを共有するためのベスト プラクティスを見つけることに特に熱心です。プロジェクト/ソリューション (ソース管理でバックアップ) を使用しますか? それともカスタム テンプレートですか?

4

2 に答える 2

5

私は両方を使用しましたが、現在は Visual Studio を使用する傾向があります。これは、MS が進んでいるように思われるためです。SQL Server 2012 では、プロジェクトは引き続きサポートされており、問題なく動作します。

正直なところ、どちらの方法でも気にする必要はありません-IMO SSMSプロジェクトはスクリプトを保存する軽量な方法であり、(個人的な好み)、データベースのみで作業している場合は、Visual StudioではなくSSMSで作業することを好みます。キー バインディングの設定方法が好きで、Query Analyzer の時代から慣れ親しんでいること以外に理由はありません。

私にとっては、単純な VS プロジェクトを作成し、そこに自分のファイルへの参照を作成するだけで、MS がこの機能を削除した場合に被るペナルティがあるため、SSMS プロジェクトを使用するだけです。

ドキュメントのこの不一致を警告するために MS Connect に何かを投稿する必要があることを伝えたいと思いますが、それから何年も経ちましたが、私が Connect で行った機能強化については、それ以外のアクションへの提案はありませんでした。 「クローズ (修正されません)」または「クローズ (設計による)」。

于 2012-08-24T20:55:06.760 に答える
2

これは古い質問であることは承知していますが、組織化されたデータベース スクリプトを使用してチームの作業を容易にする最善の方法を見つけようとしているときに、この質問に出くわしました。データベースをソース管理下に置く方法 (これを達成するための N 個の方法の 1 つ) に関する Scott Allen による 5 つの投稿シリーズを読んで、本当に素晴らしい解決策を見つけました。参考になると思いますので、シェアさせていただきます...

この投稿をチェックしてください: http://odetocode.com/blogs/scott/archive/2008/02/03/versioning-databases-branching-and-merging.aspx (これは 5 回目で最後の投稿です。投稿 1 ～ 4 の「前のエントリ」リンク)

于 2013-02-18T05:25:56.693 に答える