Разве ограничения SQL Azure не стреляют себе в ногу? - PullRequest
Новая
       7

Разве ограничения SQL Azure не стреляют себе в ногу?

2 голосов

Учитывая мой вопрос «Следует ли избегать изоляции транзакций моментальных снимков в клиентских приложениях ADO.NET? Тогда, каково было ее основное назначение?» ,
какова цель / обоснование / смысл жесткого ограничения базы данных SQL Azure:

Не является ли последнее также противоречием с базой данных SQL Azure Ограничения подключения :

  • "Ваше подключение к услуге может быть закрыто из-за следующих условий:

    • Чрезмерное использование ресурсов
    • Соединения, которые простаивали в течение 30 минут или дольше "

1 Ответ

3 голосов
/ 05 ноября 2010

SNAPSHOT-изоляция - безусловно, лучшее, что можно сделать. Единственный правильный недостаток из всех предоставленных вами ссылок - это накладные расходы на версионирование строк . Абсолютно не требуется «постоянное» соединение с базой данных для использования изоляции SNAPSHOT. Статья Дана Гусмана, на которую вы ссылаетесь, в лучшем случае вводит в заблуждение. Хотя он не выдвигает ложных утверждений, то, как он формулирует проблему, приводит к ложным выводам.

Вы всегда можете разработать свои приложения, используя оптимистическую модель параллелизма для обновлений:

Читать: 

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 и получать оптимистичный контроль параллелизма. В статье приведен пример параллелизма, который опирается на изоляцию SNAPSHOT, а не на оптимистичный контроль параллелизма, но, конечно, при этом молча изменил все в приложении: во втором примере чтение и Запись должна происходить в той же транзакции , поэтому она больше не является тем же сценарием, что и первый пример (она не может быть типичным чтением-отображением-пост-обновлением в качестве первого сценарий).

Так что нет, SQL Azure не стреляет себе в ногу. Также SNAPSHOT-изоляция не требует постоянных соединений. Кроме того, изоляция SNAPSHOT непригодна для ASP.Net. Боюсь, я должен сказать, что вам нужно намного лучше фильтровать свои данные. Немного покопайтесь в том, что вы найдете в интербубах, предположите, что все не так, пока не доказано, что это правильно, придерживайтесь официальных спецификаций продукта и избегайте блогов, экспертов или форумов / сайтов ответов, таких как stackoverflow ...

...