我最近一直在阅读 LINQ 以开始实现它，关于它如何生成困扰我的 UPDATE 查询有一件特别的事情。
使用 SQLMetal 或对象关系设计器自动创建实体代码，显然所有表的所有字段都将获得属性UpdateCheck.Always，这意味着对于每个 UPDATE 和 DELETE 查询，我将得到如下 SQL 语句：
UPDATE table SET a = 'a' WHERE a='x' AND b='x' ... AND z='x', ad infinitum
现在，称我为纯粹主义者，但这对我来说似乎非常低效，而且无论如何感觉都是个坏主意，即使它不是低效的。我知道获取将由集群主键完成，所以这并不慢，但 SQL 仍然需要检查之后的每个字段以确保它匹配。
当然，在一些非常敏感的应用程序中，这样的东西可能很有用，但对于典型的 Web 应用程序（想想 Stack Overflow），似乎UpdateCheck.WhenChanged将是更合适的默认值，我个人更喜欢UpdateCheck.Never，因为LINQ 只会更新已更改的实际字段，而不是所有字段，并且在大多数实际情况下，无论如何，编辑某些内容的第二个人都会获胜。
这确实意味着，如果两个人设法在读取该行和触发 UPDATE 之间的一小段时间内编辑同一行的同一字段，那么将不会触发所发现的冲突。但实际上这是非常罕见的情况。当两个人更改相同的东西时，我们可能要提防的一件事不会被这个抓住，因为他们不会在完全相同的时间点击提交，所以在第二个 DataContext 时不会发生冲突读取并更新记录（除非在显示页面时 DataContext 保持打开状态并存储在 Session 中，或者其他一些非常糟糕的想法）。
但是，尽管这种情况很少见，但如果发生这种情况，我真的不想时不时地在我的代码中出现异常。
所以我的第一个问题是，我相信这个有错吗？（同样，对于“典型的”网络应用程序，而不是银行应用程序）我是否错过了为什么将 UpdateCheck.Always 作为默认设置是一个理智的想法的一些原因？
我的第二个问题是，我可以文明地改变这一点吗？有没有办法告诉 SQLMetal 或 ORD 设置哪个 UpdateCheck 属性？
我试图避免我必须记住运行一个工具的情况，我将不得不使用一些正则表达式并直接编辑文件中的所有属性，因为很明显，在某些时候我们会运行SQLMetal 在数据库更新后，我们不会运行这个工具，而且我们所有的代码都会以非常微妙的方式中断，我们在 dev 中测试时可能不会发现。
有什么建议么？
战争故事非常受欢迎，我很想从其他人的经验中学习。
非常感谢你！