仅使用存储过程来访问具有合并复制的数据库是否有优势？
我有一个项目，其中 SP 是应用程序用来访问或修改 Sql Server 2008 DB 的唯一方式。 我有开发人员要求放弃仅 SP 的方法，让他们直接在 DB 上使用 Linq to Sql。我必须决定是否允许这样做。 我必须添加另一条信息，该项目正在增长，在不久的将来我们可能需要第二台具有合并复制功能的 Sql 服务器计算机。
我这么说是因为我相信（但我现在在 Internet 上找不到对此的任何支持）仅使用 SP 方法在合并复制场景中是有益的，因为这将避免冲突并带来更好的性能。
这种说法有道理吗？您能链接到证明或反驳这一说法的参考文献吗？你有什么意见？
这已成为做出决定的决定性因素。
I have a project where SPs are the only way that the application uses to access or modify the Sql Server 2008 DB.
I have developers asking to abandon the SP only approach and let them use Linq to Sql on the DB directly. I have to decide if to allow this or not.
I have to add another piece of information, the project is growing and in the near future we might need a second Sql server machine with merge replication.
I said this because I believed (but I don't find any support to this on the Internet now) that having a SP only approach it's beneficial in a merge replication scenario as this will avoid conflicts and result in a better performance.
Is there any truth to this statement? Could you link to the reference that proves or disproves this statement? What's your opinion?
This has come down to be the decisive factor to make the decision.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不认为存储过程或任何其他更改数据的方法实际上是合并复制中的一个因素，因为进行更新不会直接触发将更改推送到分发数据库中。
例如，如果您通过存储过程或通过 Linq to Sql 编辑一行，则更改跟踪、合并和发布是相同的。
有一个关于并发问题的可能性的问题，建议对这种情况进行测试。
如果您使用 Linq to SQL，则需要确保了解何时执行语句 - 这并非特定于合并复制。
我的最后一点是照顾那些为了改变而改变的开发人员。 Linq to SQL 将为您的特定应用程序带来什么好处？在选择 Linq to SQL 之前，您还看过哪些其他数据访问解决方案。
仅仅因为 Linq to SQL 对于某些应用程序来说非常有用，但这并不意味着它对于每个应用程序都是完美的，我认为这应该会影响您的决定。
就您个人而言，我会保留存储过程，直到您完全隔离数据访问 - 这是现阶段更重要的任务。
I don't think Stored Procedures or any other method of changing the data is really a factor in Merge Replication as making an update doesn't directly trigger the change to be pushed down into the distribution database.
For example, if you edit a row via a stored procedure or via Linq to Sql, the change tracking, merging and publishing is the same.
There is a question about the potential for concurrency issues, and the advice is to test for this scenario.
If you are using Linq to SQL you need to make sure you understand when a statement will be executed - this is not specific to Merge Replication.
My final point is to take care of developers who want change for the sake of change. What benefit will Linq to SQL bring to your specific application? What other data access solutions have you looked at before you chose Linq to SQL.
Just because Linq to SQL is great for some applications, it doesn't mean it is perfect for every application and this is what I think should be influencing your decision.
Personally, in your case I would keep stored procedures until you have fully isolated your data access - that is a more important task at this stage.