Бывают случаи, когда нужно ограничить пользователям доступ к некоторым данным в кубе. Казалось бы, тут нет ничего сложного: устанавливай построчные фильтры в ролях и готово, но есть одна проблема — фильтр урезает данные в таблице и получается, что можно посмотреть обороты только по доступным строкам, а нам нужны все обороты, но детализация должна быть доступна только для части из них.

Например, пользователь должен видеть обороты по всем товарам, с возможностью полной детализации по ним, но клиенты при этом должны отображаться не все, а лишь некоторые, либо все клиенты, но с частично скрытыми данными в некоторых атрибутах (полях).

Чтобы не дать пользователю возможность просматривать обороты в разрезе клиентов, можно обыграть это через формулы в мерах и выводить пустое значение, если пользователь попытается посмотреть оборот конкретного клиента, один из подобных вариантов описан здесь. Однако это всё не то. Когда мер несколько десятков, то писать в каждой из них формулу… а если забудешь? Но ведь точно забудешь же когда-нибудь… А если пользователю нужны данные из конкретной карточки клиента, то ему ни что не помешает это увидеть без выбора фильтрующей меры. Что же делать?

Нам нужно было добиться вот такого отображения:

Как известно, из коробки Excel не позволяет устанавливать фильтры по списку значений для сводных таблиц, а это ведь такая нужная вещь! Как отфильтровать товары по сотне кодов, а потом по другой сотне? Есть, конечно, способы, но все это не то…

Или, например, установить для куба фильтр по измерению с датами, но не проставлять галочки на каждом дне/месяце/годе, а задать диапазон С… ПО ....

---

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

Мы запилили на VBA расширение, добавляющее на ленту панель Инструменты куба с волшебными кнопочками.

Время течет и скоро от этой разработки почти ничего не останется, а у меня все никак не находилось времени ее описать.



Речь пойдет о компании федерального уровня с большим числом филиалов и подфилиалов. Но, как обычно, все началось давным-давно с одного маленького магазина. С течением лет шло достаточно быстрое и стихийное развитие, появлялись филиалы, подразделения и прочие офисы, а ИТ-инфраструктуре не уделялось в те времена должного внимания, и это тоже частое явление. Конечно же, везде использовалась 1С77, без задела на какие-либо репликации и масштабирование, поэтому, сами понимаете, в конце пришли к тому, что был порожден спрут-франкенштейн с примотанными изолентой щупальцами — в каждом филиале автономный мутант, который с центральной базой обменивался в «наколеночном» режиме лишь несколькими справочниками, без которых ну вообще никак было нельзя, а остальное автономно. Какое-то время довольствовались копиями (десятки их!) филиальных баз в центральном офисе, но данные в них отставали на несколько дней.

Реальность же требует получать информацию более оперативно и гибко, а еще надо что-то с этим делать. Пересесть с одной учетной системы на другую при таких масштабах — то еще болото. Поэтому было решено сделать хранилище данных (ДХ), в которое стекалась бы информация из разных баз, чтобы впоследствии из этого ХД могли получать данные другие сервисы и аналитическая система в виде кубов, SSRS отчетов и протча.

Забегая вперед скажу, что переход на новую учетную систему почти уже случился и бОльшая часть проекта, описываемого здесь, будет выпилена в ближайшее время за ненадобностью. Жаль, конечно, но ничего не поделаешь.

Далее следует длинная статья, но прежде чем начнете читать, позвольте заметить, что ни в коем случае не выдаю это решение за эталон, однако может кто-то найдет для себя в ней что-то полезное.

Если вам приходилось иметь дело с кубом, в котором число мер и измерений over9000 и не хватает трех экранов, чтобы это уместить, то, наверняка, приходилось слышать и стоны пользователей, на тему неудобства работы с этим чудовищем. Ведь пользователи чаще всего работают с одними и теми же измерениями, без которых не обходится почти ни одна выборка. Однако из-за особенности экселя, любящего сортировать по алфавиту все элементы, находящиеся в области Поля сводной таблицы, эти наиболее востребованные объекты часто разбросаны по всему списку, вперемешку с остальными (редко используемыми) элементами.


Приходится десять раз скролить список вверх и вниз, пока пытаешься установить фильтр на трёх (Дата, Товар, Клиент) полях. Работать с этим каждый день никаких нервов не хватит.

Решение банальное и не новое — в начале имен измерений добавлять символ или цифру, влияя тем самым на порядок.

Но пользователи — это одна сторона медали, им такой подход удобен. А как же разработчики?
Ведь оно как должно быть: начинаешь писать в формуле имя измерения, а студия подсказки выдает, верно? Вот только в случае с допсимволами все это выглядит в коде, скажем так… не очень. В VS2017 уже сделали поиск по вхождению, а в предыдущих такого не было и приходилось писать Календарь не с буквы К, а с цифры 5, потому что 5 Календарь. Запросы в других программах приходится писать без подсказок и упомнить какая цифра у какого измерения или поля — тот еще квест.



Когда нужно изменить порядок, то, по сути, нужно переименовать таблицу или поле, а если это поле используется в формуле, то студия исправит и формулу. Когда формул десятки (а их всегда десятки), то в Git будет подсвечиваться половина модели, потому что студия реально все формулы исправила, в то время как я хотел только поменять поля местами в порядке сортировки. Запросы же в других источниках (за пределами студии) поломаются вообще. Крайне неудобно!

Но выход есть.

24 сентября была представлена первая редакция CTP выпуска SQL Server 2019, и, позвольте сказать, что он переполнен всевозможными улучшениями и новыми возможностями (многие из которых можно найти в форме предварительного просмотра в базе данных SQL Azure). У меня была исключительная возможность познакомиться с этим чуть раньше, позволившая мне расширить представление об изменениях, пусть даже поверхностно. Вы можете также ознакомиться с последними публикациями от команды разработчиков SQL Server и обновленной документацией.

Не вдаваясь в подробности, я собираюсь обсудить следующие новые функций ядра: производительность, поиск и устранение неполадок в работе, безопасность, доступность и разработка. На данный момент у меня есть немного больше подробностей, чем у других, и часть из них уже подготовлена к публикациям. Я вернусь к этому разделу, как и к множеству других статей и документации и опубликую их. Спешу сообщить, что это не всеобъемлющий обзор, а только часть функционала, которую я успел «пощупать», вплоть до CTP 2.0. Еще есть много всего, о чем стоит рассказать.

Неделю или две назад я увидел сообщение на форуме RabbitMQ Users, о том, как наладить отправку сообщений из SQL Server в RabbitMQ. Поскольку мы плотно с этим работаем в Derivco, я оставил там некоторые предложения, а также сказал, что пишу в блоге о том, как это можно сделать. Часть моего сообщения была не совсем верной — по крайней мере, до этого момента (сорри, Бро, был очень занят).

Потрясающая штука, этот ваш SQL Server. С его помощью очень легко поместить информацию в базу данных. Получить данные из базы с помощью запроса столь же просто. А вот получить только что обновленные или вставленные данные уже немного сложнее. Подумайте о событиях в реальном времени; совершена покупка — кого-то нужно уведомить об этом в тот же момент, как только это произошло. Возможно, кто-то скажет, что такие данные должны выталкиваться не из базы данных, а откуда-то еще. Безусловно, так оно и есть, но довольно часто у нас попросту нет выбора.

Нельзя просто так взять и ответить на этот вопрос, не приняв во внимание целый ряд факторов.

Многие думают, что необходимо переходить на табличную модель, ибо она новее и лучше. Но часто это нецелесообразно или даже невозможно в принципе. Однако поговорим об этом чуть позже.

Многомерная модель

Многомерная база данных имеет определенную структуру и позволяет нам генерировать отчеты очень быстро. Когда-то, для создания многомерных баз данных, многомерная модель была единственным решением. Эта модель не менялась со времен SQL Server 2005. Если посмотреть что нового в каждом выпуске Analysis Services, то станет ясно, что большинство новшеств связано именно с табличной моделью.

Табличная модель

Табличная модель появилась в SQL Server 2012 и активно развивается, а каждая последующая версия включают новые возможности.

Табличная модель работает на другом движке (xVelocity) и она разработана для быстрого выполнения колоночных запросов, потому что использует колоночное хранение (многомерные модели используют строковое хранение), в дополнение к хорошему сжатию данных. Данные хранятся в оперативной памяти (режим in-memory), поэтому очень важно, чтобы на сервере было много памяти и очень быстрый процессор. Диски для табличной модели не так важны. Одним из основных преимуществ табличной модели является то, что некоторые запросы в ней работают быстрее (например, очень быстро работают с измерениями на основе distinct count) и она имеет высокую степень сжатия — 1/10 (ниже приведена ссылка с описанием принципа сжатия), в то время как в многомерной модели лишь 1/3. Степень сжатия указана примерная, разумеется, она может колебаться, в зависимости от данных.

Меня часто спрашивают об основных отличиях DAX и MDX или в целом о различии табличной и многомерной модели.

С точки зрения выражения или языка запросов, одно из наиболее важных различий лежит во внутренней основе обоих подходов.

В кубе, для адресации ячейки в пространстве, у нас есть понятие кортежа. Ось в кортеже устанавливает координаты. Если у нас есть единственный кортеж, то результат — содержание соответствующей ячейки в кубе. Поскольку у атрибутов куба есть элемент All, который служит значением по умолчанию (в большинстве случаев), если атрибут не был включен в кортеж, то мы выполняем агрегацию также, как если бы он там был. Например, следующий кортеж возвращает (агрегированный) объем продаж за 2013 год

(Date.Calendar.[Calendar Year].&[2013], Measures.[Internet Sales Amount])

Кто-то задал такой вопрос:

Мне нужно создать таблицу group со столбцом code. Можно ли добавить ограничение на столбец, которое допускало бы только буквенные символы (D, M, O, P или T) с последующими двумя цифровыми символами?

Ему ответили:

Вы не можете этого сделать обычным способом — MS SQL Server поддерживает проверку ограничений, но лишь в виде мин/макс значения INT, длины строки и т.п. То, что вам нужно, — проверка на основе регулярного выражения, которую SQL Server не поддерживает. Теоретически можно сделать .NET вставку, развернуть на SQL Server и заставить его использовать такую проверку — нетривиальная задача.

Попробуем разобраться

Не смотря на то, что SQL server не поддерживает регулярные выражения в полной мере, но поставленную выше задачу можно без проблем решить и на T-SQL. Вот так будет выглядеть это регулярное выражение

[DMOPT][0-9][0-9]

Оно допускает только буквенные символы (D, M, O, P или T) с последующими двумя цифровыми символами. Ладно, хватит разговоров, давайте перейдем к коду

Привет, Хабр! Представляю вашему вниманию перевод статьи SQL Server Insert Performance for Clustered Indexes vs. Heap Tables

Вопрос

Я прочел множество различной документации по современным методам работы с SQL Server, утверждающей, что каждая таблица должна иметь кластеризованный индекс и не быть кучей с некаластеризованными индексами. Большинство источников отмечает административную выгоду от использования кластеризованных индексов. Но есть ли в этом какое-то влияние на производительность и другие положительные или отрицательные стороны?