アプリケーションが Sql Server 2008 DB にアクセスまたは変更するために使用する唯一の方法が SP であるプロジェクトがあります。SP のみのアプローチを放棄し、Linq to Sql を DB で直接使用できるようにするよう開発者に求めています。これを許可するかどうかを決定する必要があります。別の情報を追加する必要があります。プロジェクトは成長しており、近い将来、マージ レプリケーションを備えた 2 台目の SQL サーバー マシンが必要になる可能性があります。
私がこれを言ったのは、SP のみのアプローチが競合を回避し、パフォーマンスが向上するため、マージ レプリケーション シナリオで有益であると信じていたからです (ただし、現在インターネット上でこれに対するサポートは見つかりません)。
この声明に真実はありますか？この声明を証明または反証する参考文献にリンクしていただけますか? あなたの意見は何ですか？
これが決定を下す決定的な要因になりました。
ストアド プロシージャやデータを変更するその他の方法が実際にマージ レプリケーションの要因になるとは思いません。更新を行っても変更がディストリビューション データベースに直接プッシュされるわけではないからです。
たとえば、ストアド プロシージャまたは Linq to Sql を介して行を編集する場合、変更の追跡、マージ、および発行は同じです。
同時実行の問題の可能性について質問があり、このシナリオをテストすることをお勧めします。
Linq to SQL を使用している場合は、ステートメントがいつ実行されるかを理解しておく必要があります。これはマージ レプリケーションに固有のものではありません。
最後のポイントは、変化のために変化を求める開発者の世話をすることです。Linq to SQL は特定のアプリケーションにどのようなメリットをもたらしますか? Linq to SQL を選択する前に、他に検討したデータ アクセス ソリューションはありますか。
Linq to SQL が一部のアプリケーションに適しているからといって、すべてのアプリケーションに最適であるとは限りません。これは、あなたの決定に影響を与えるべきだと思います。
個人的には、あなたの場合、データ アクセスを完全に分離するまでストアド プロシージャを保持します。これは、この段階ではより重要なタスクです。