c# - SQL Azure 的限制不是搬起石头砸自己的脚吗？

Question

考虑我的问题"Should snapshot transaction isolation be avoided in client ADO.NET applications? then, what was its main purpose?" ,
SQL Azure 数据库严格限制的目的/理由/意义是什么:

• "Both the READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION database options are set to ON in SQL Azure Database. Because SET in the ALTER DATABASE Transact-SQL statement is not supported, these database options cannot be changed"

后者是否也与 SQL Azure 数据库相矛盾 Connection Constraints :

• “您与服务的连接可能会由于以下情况而关闭:

  • 资源使用过多
  • 空闲时间达到或超过 30 分钟的连接”

Answer 1

快照隔离绝对是迄今为止最好的选择。从您提供的所有链接来看，唯一正确的缺点是 overhead of row versioning 。为了使用快照隔离，绝对不需要“持久”数据库连接。您链接的丹·古兹曼的文章充其量只是误导性的。虽然它没有提出错误的主张，但它阐述问题的方式会导致错误的结论。

您始终可以使用更新乐观并发模型来开发应用程序:

阅读:

SELECT
      ContactName,
      ContactTitle
FROM dbo.Suppliers
WHERE SupplierID = @SupplierID;

写:

UPDATE dbo.Suppliers
SET
      ContactName = @NewContactName,
      ContactTitle = @NewContactTitle
WHERE
      SupplierID = @SupplierID AND
      ContactName = @OriginalContactName AND
      ContactTitle = @OriginalContactTitle;

IF @@ROWCOUNT = 0 --a zero rowcount indicates data was deleted or changed
BEGIN
      RAISERROR ('Contact information was changed by another user', 16, 1);
END;

绝对不要求读取和写入应发生在同一连接中。绝对肯定的是，您可以在快照隔离下进行读写并获得乐观并发控制。本文给出了一个依赖于 SNAPSHOT 隔离而不是乐观并发控制的并发示例，但当然，这样做已经默默改变了应用程序的一切:在第二个示例中读取和写入必须发生在同一事务中，因此不再是与第一个示例相同的场景(它不能是典型的读取-显示-后处理更新为第一个场景)。

所以，SQL Azure 不会搬起石头砸自己的脚。快照隔离也不需要持久连接。 SNAPSHOT 隔离也不能与 ASP.Net 一起使用。恐怕我不得不说你需要更好地过滤你的输入。仔细研究你在管间找到的东西，假设一切都是错的，直到被证明是正确的，坚持官方产品规范并避免博客、专家或论坛/答案网站(如 stackoverflow)...