А какая редакция подразумевается?
Если стандарты - там пропасть новых нужных вещей.
В 2017 - секционирование, колоночные индексы, сжатие данных - как минимум.

msLexNika gnomeНикак не могу найти где-нибудь статью, которая бы объясняла, что такого принципиально нового появилось за 7 лет.

Ну, т.е. например, SQL Server 2008r2. (Цель - хранилище данных, BI). Чем 2017-й лучше?

Что там такого, без чего ну никак? R и Python появился.
Тупой вопрос, конечно, но просто пытаюсь найти по существу информацию, что такого появилось, сколько добавилось сотен новых функций, запросов, возможностей - но не нахожу. Кто-нибудь знает, где просмотреть эту информацию?

Кстати, в разрезе SSAS и SSIS тоже было бы интересно узнать.

разницу между 2017 и 2008 r2 можно собрать "сагрегировав" what's new для каждой мажорной версии старше 2008 r2 (2012, 2014, 2016, 2017)
Опять же, рассматривать различие только мажорных версий - нельзя.
Например - сжатие данных, сжатие бэкапов и секционирование в 2008r2 - в энтерпрайзе, а в 2017 - есть в стандарте.
И, например, для маленьких серверов, <256 ГБ ОЗУ и <10-20Гб базы - 2017 стандарт вполне заменяет 2008 энтерпрайз, если не нужно онлайн перестроения индексов.
Но, опять же, если предусматривается такой переход то из новых вкусностей - только колоночные индексы (в контексте BI), и я не уверен, оправдан ли такой переход с понижением редакции.
Ну, может быть, еще BPE можно на каком-нибудь оптане организовать, но я не уверен в полезности этого мероприятия именно для BI.
Переход с энтерпрайза на энтерврайз, конечно, приятнее, т.к., по пути, вроде, ничего не потерялось, конкретно для BI, из существенного, вроде только колоночные индексы добавились. Т.е., я не уверен, что из экономистов удастся аргументированно выбить деньги на апгрейд.
Если я не прав - поправьте, пожалуйста.
Мне интересно.

Yuri Abeleдобавлю к вышесказанном:

RDBMS:
- Еще Change Tracking удобен шибко для инкрементарной подгрузки.
- Встроенные средства парсинга JSON

[SSIS]
- SSIS catalog
- Project Configuration & Deployment
Если у них 2008r2 и была реализована инкрементальная загрузка, то они, скорее всего, путем добавления в таблицы поля rowversion/timestamp, так что Change Tracking вряд ли добавит что-то новое. Это если только с нуля реализовывать. Хотя да, согласен.
Очень приятны, кстати, иногда, темпоральные таблицы.
Но вряд-ли эти для BI. Ну, я не знаю, только изменения справочников отслеживать.

Еще, кроме парсинга json, они что-то с импортом csv сделали, полезное. Но не вникал.
Очень приятен Query Store. Но это опять же не для BI.

Для BI, безусловно, киллер-фича - это колумнсторы, причем - кластерные колумнсторы и обновляемые без плясок с бубнами колумнсторы, а также постраничное сжатие во всех редакциях. Жаль параллельное сканирование колумнстора - только в энтерпрайзе.
Еще в принципе может пригодиться стрэйчинг в ажур, но это а) для энтерпрайза, и б) не для всех пользователей (в смысле - не всем показаны облака).

-- KAB --uaggsterА какая редакция подразумевается?
Если стандарты - там пропасть новых нужных вещей.
В 2017 - секционирование , колоночные индексы, сжатие данных - как минимум.
Вы уверены что секционирования не было в 2008м?
Вы уверены что сжатие данных не было в 2008м? ))))
Колоночных индексов в 2008м не было... но первые появились в 2012м
Я уверен , что секционирования и сжатия не было в 2008 в редакции standard . А было только в enterprise .
Именно поэтому и спросил: "какая редакция подразумевается".
Потому что переход со стандарта на стандарт - даст довольно много нового и нужного для BI. А с энтерпрайза на энтерпрайз - фактически, из действительно важного, только колоночные индексы.
И переход со стандарта 2008 на стандарт 2017, эквивалентна переходу на энтерпрайз 2008, за минусом онлайн перестроения индексов.
Поэтому, со стандарта 2008 на стандарт 2017 (ну, или энтерпрайз), с т.з. расширения возможностей - переходить нужно, а вот с энтерпрайза на энтерпрайз - нужно смотреть, так ли уж нужны колумнсторы.
Например, если у них вся аналитика - в кубах, а хранилище - только как источник данных для кубов - то это нинафиг не нужно.
(Хотя, может быть, данные жать кластерным колумнстором).