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

Question

考虑我的问题“是否应该避免快照事务隔离那么，它的主要用途是什么？”,
SQL Azure 数据库严格限制的目的/原理/意义是什么：

• "在 SQL Azure 数据库中，READ_COMMITTED_SNAPSHOT 和 ALLOW_SNAPSHOT_ISOLATION 数据库选项均设置为 ON，因为不支持 ALTER DATABASE Transact-SQL 语句中的 SET，因此无法更改这些数据库选项”

不是后者吗？与 SQL Azure 数据库矛盾连接约束：

• "由于以下情况，您与服务的连接可能会被关闭：

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

Answer 1

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

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

读取：

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...