Самая большая ложка дегтя с интеграционными тестами — это время выполнения, они намного медленнее, но это решаемая проблема.
У Вас БД для каждого теста пересоздается? Если да, то может помочь Instant File Initialization. Либо лучше базу вообще один раз создать, а потом использовать database snapshot для каждого теста. Начиная с 2016 SP1 эта функциональность и в Express редакции доступна.
Как сделать быстрее тут когда-то публиковал про Delayed Durability. Для OLTP нагрузки как раз поможет снизить выполнение Ваших тестов.
Вообще то это не про него было :) хотя помню было время мне приходилось писать статейки на его сайт, а он подписывался своим именем под них. К слову эту же статью в переводе разместили у Пинала :) и убрали упоминание про индусов.
Если отдавать JSON, то это возможно и является хорошим новшеством SQL Server 2016, но вот проблемы при хранении JSON обеспечены точно (особенно в сравнении с XML который сжимается изначально).
Индексов создать на JSON нельзя (по аналогии с selective xml indexes которые доступны с SQL Server 2012 SP1) и возможно только вычисляемые поля выход из положения…
Какие именно инструменты Вы имеете ввиду? Из того что я знаю можно заюзать только SQL Monitor от RedGate либо смотреть в сторону монстра от SQL Sentry. В любом случае все они платные.
С этим не соглашусь что тестируется все тщательно. То и дело после каждого CU то хинт NOLOCK к блокировкам приводит (это из последних приколов), то всякие траблы с производительностью вылазят. Я как ставил SP так это и делаю… и то опять же после того как все протестирую.
По поводу актуальности можно поспорить… vNext не относится к 2016-му. На последней версии SQL Server 2016 SP1 (13.0.4001.0) вот такое мы получим:
Msg 195, Level 15, State 10, Line 4
'STRING_AGG' is not a recognized built-in function name.
Хотя к слову, крайне советую ознакомиться с изменениями в новом SP1 для 2016-го.
В Express, Standart редакциях можно наконец-то использовать секционирование и columnstore индексы. С небольшими оговорками конечно, но все равно круто :)
Если про даты еще ладно… у каждого проекта свои особенности. Но вот с NOT NULL приколом сталкивался регулярно, когда старые базы саппортил. Знать об этом надо!
… а лучше всего использовать ORM и не мучаться с «сырыми» запросами.
Вот тут не согласен. Зачем так категорично? :)
Относительно индексированных представлений… OLTP или DW? Их не всегда выгодно применять. Там много приколов, особенно когда присутствует неслабая OLTP нагрузка.
Ситуации бывают разные. Например, у меня пару проектов уровня Enterprise крутились на экспресс версии SQL Server 2014. Ни секционирования, ни колумсторов… в дополнении ограничен гигом оперативы и медленным диском. Так чтобы все «помещялось» в BufferPool такие заморочки с типами данных как раз были бы не лишними.
И да… и нет… это все зависит от оптимизатора. Например, наши примеры работать будут, но MS не гарантирует этого поведения всегда (именно поэтому не рекомендуется так делать):
DECLARE @a VARCHAR(MAX)
;WITH
E1(N) AS (
SELECT * FROM (
VALUES
('1'),('1'),('1'),('1'),('1'),
('1'),('1'),('1'),('1'),('1')
) t(N)
),
E2(N) AS (SELECT '1' FROM E1 a, E1 b),
E4(N) AS (SELECT '1' FROM E2 a, E2 b)
SELECT @a = COALESCE(@a + ',', '') + N
FROM E4
ORDER BY LEN(N)
SELECT @a
Увы хорошее репро у меня было только одно, что я привел в статье.
То что на 2005 нету типа DATE еще не говорит о том, что эта версия себя как-то по особенному ведет. Там тоже нужно следить за форматом строковой константы для даты. Или Вы имели ввиду какой-то отдельный случай?
Все что я описал сохраняет актуальность с 2005 версии и по 2016 (за мелкими исключениями, потому что кое где планы выполнения будут другими).
Поддерживаю Ваше мнение. Но все же старался донести мысль, что чаще всего курсоры применяют там где они не нужны. Если не брать во внимание административных задач и совсем древних версий (вроде SQL Server 2005), то я раза два-три вынужденно использовал курсоры и они задачу решали намного быстрее.
Поддерживаю. Однако, Plan Explorer я бы не торопился списывать со счетов, потому что он хорош как раз в мелочах. То что показывает разницу между актуальным и ожидаемым планом выполнения, что можно «проиграть» выполнения запроса и увидеть на каком этапе был затык. Такого SSMS не умеет увы.
Единственный минус, что он не является плагином который в SSMS можно встроить вместо стандартной закладки. Хотя знаю по некоторой инсайдерской информации, что скоро выйдет тул от ApexSQL с более крутым функционалом. Я его немного уже попробовал — шероховатости есть, но мне понравилось.
Как бы критиковать пост не хотел изначально. Но все же зачем так явно пиарить?
Из того с чем согласен… в этом туле нормальный форматтер, Intelligence и Index Manager. Схема компаратор сейчас сливает RedGate по скорости за счет частичного дескрайба в последнем + не всегда скрипты генерятся правильно (вместо ALTER часто таблица пересоздается — это актуально для 2014 версии сиквела). Дата компаратор хороший, но скрипты по синхронизации не всегда генерит оптимальные. Из-за чего работа в этом туле для админа на большой базе приятной явно не будет. Execution Plan хороший, но проигрывает во многом бесплатному PlanExplorer… скоро это в теории должно изменится с новым релизом. Производительность при работе с гридом где результаты запроса выводятся — это печаль надолго… из-за того что данные часто курсорами выгребаются из таблицы. InMemory, секционирование, компрессия и прочие интересные плюшкки поддержаны не полностью.
Итого получается, что для чего-то серьезного этот тул ИМХО не подойдет. Лично мне удобнее связка SSMS+SSDT+плагины.
А если так, то сколько будет? :)
У Вас БД для каждого теста пересоздается? Если да, то может помочь Instant File Initialization. Либо лучше базу вообще один раз создать, а потом использовать database snapshot для каждого теста. Начиная с 2016 SP1 эта функциональность и в Express редакции доступна.
Как сделать быстрее тут когда-то публиковал про Delayed Durability. Для OLTP нагрузки как раз поможет снизить выполнение Ваших тестов.
Индексов создать на JSON нельзя (по аналогии с selective xml indexes которые доступны с SQL Server 2012 SP1) и возможно только вычисляемые поля выход из положения…
Хотя если выключить сарказм, то продукт перспективный. Но его еще долго нужно развивать
Msg 195, Level 15, State 10, Line 4
'STRING_AGG' is not a recognized built-in function name.
Хотя к слову, крайне советую ознакомиться с изменениями в новом SP1 для 2016-го.
В Express, Standart редакциях можно наконец-то использовать секционирование и columnstore индексы. С небольшими оговорками конечно, но все равно круто :)
Вот тут не согласен. Зачем так категорично? :)
Относительно индексированных представлений… OLTP или DW? Их не всегда выгодно применять. Там много приколов, особенно когда присутствует неслабая OLTP нагрузка.
Увы хорошее репро у меня было только одно, что я привел в статье.
Все что я описал сохраняет актуальность с 2005 версии и по 2016 (за мелкими исключениями, потому что кое где планы выполнения будут другими).
Единственный минус, что он не является плагином который в SSMS можно встроить вместо стандартной закладки. Хотя знаю по некоторой инсайдерской информации, что скоро выйдет тул от ApexSQL с более крутым функционалом. Я его немного уже попробовал — шероховатости есть, но мне понравилось.
Из того с чем согласен… в этом туле нормальный форматтер, Intelligence и Index Manager. Схема компаратор сейчас сливает RedGate по скорости за счет частичного дескрайба в последнем + не всегда скрипты генерятся правильно (вместо ALTER часто таблица пересоздается — это актуально для 2014 версии сиквела). Дата компаратор хороший, но скрипты по синхронизации не всегда генерит оптимальные. Из-за чего работа в этом туле для админа на большой базе приятной явно не будет. Execution Plan хороший, но проигрывает во многом бесплатному PlanExplorer… скоро это в теории должно изменится с новым релизом. Производительность при работе с гридом где результаты запроса выводятся — это печаль надолго… из-за того что данные часто курсорами выгребаются из таблицы. InMemory, секционирование, компрессия и прочие интересные плюшкки поддержаны не полностью.
Итого получается, что для чего-то серьезного этот тул ИМХО не подойдет. Лично мне удобнее связка SSMS+SSDT+плагины.