Microsoft SQL Server *

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

Привет!

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

Так вот. Часто ли вы используете в своём C#-проекте с настроенным ORM-ом прямые SQL-запросы в базу? Ой, да бросьте, не отнекивайтесь. Используете. Иначе как бы вы реализовывали удаление/обновление сущностей пачками и оставались живы…

Что мы больше всего любим в прямом SQL? Скорость и простоту. Там, где "в лучших традициях ORM" надо выгрузить в память вагончик объектов и всем сделать context.Remove (ну или поманипулировать Attach-ем), можнo обойтись одним мааааленьким SQL-запросом.
Что мы больше всего не любим в прямом SQL? Правильно. Отсутствие типизации и взрывоопасность. Прямой SQL обычно делается через DbContext.Database.ExecuteSqlCommand, а оно на вход принимает только строку. Следовательно, Find Usages в студии никогда не покажет вам какие поля каких сущностей ваш прямой SQL затронул, ну и помимо прочего вам приходится полагаться на свою память в вопросе точных имён всех таблиц/колонок которые вы щупаете. А ещё молиться, что никакой лоботряс не покопается в вашей модели и не переименует всё в ходе рефакторинга или средствами EntityFramework, пока вы будете спать.

Так ликуйте же, адепты маленьких raw SQL-запросов! В этой статье я покажу вам как совместить их с EF, не потерять в майнтайнабильности и не наплодить детонаторов. Ныряйте же под кат скорее!

Введение

Базы данных пришли в мир в 70 году. С тех пор они стали больше по размеру, с более сложной логикой и продолжают расти. С тех пор появилось много инструментов для синтаксического анализа SQL и выстраивания зависимостей. Все они разбивают SQL на токены, используя тот или иной синтаксический анализатор и грамматики.

Но обычные синтаксические анализаторы (ANTLR, например) могут столкнуться с ошибками разбора скриптов, каждый диалект SQL имеет свои собственные особенности. Время анализа тоже может быть существенным на больших БД.

Я хочу показать намного более простой способ: RegEx + небольшой трюк,
итак…

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

В сентябре компания DataCore представила новую линейку продуктов MaxParallel и первый продукт из серии — MaxParallel for SQL Server. MaxParallel делает простую вещь – ускоряет работу базы данных MS SQL, не требуя для этого никаких изменений самой базы (ее оптимизации и тп.) или аппаратной части (увеличения числа процессоров, памяти и тп.).

В чем идея: практически все современные сервер БД являются многоядерными, и приложения с успехом используют эти ядра для параллелизации вычислений. Но процесс ввода-вывода остается последовательным и использует одно процессорное ядро. И если заставить планировщик ввода-вывода использовать больше процессорных ресурсов, БД будет работать быстрее. По крайней мере, сможет работать быстрее. Уникальность MaxParallel состоит не только в том, что она ускоряет БД без серьезного вмешательства, но также в том, что она устраняет «узкое место», которое по-другому не устранить.

Существует компания, предоставляющая платформу для работы с большими данными. Эта платформа позволяет хранить генетические данные и эффективно управлять ими. Для полноценной работы платформы требуется возможность обрабатывать динамические запросы в среде выполнения не более чем за две секунды. Но как преодолеть этот барьер? Для трансформации существующей системы было решено использовать хранилище данных SQL. Заглядывайте под кат за подробностями!

Написать эту статью меня побудила заметка уважаемого jobgemws "Отправка запроса на все базы данных всех указанных серверов на примере MS SQL Server и C#.NET"

Я расскажу, как схожую задачу можно решить штатными инструментами MSSQLSERVER, а именно – SSMS (или, для экстремалов от администрирования — sqlcmd), быстро, без программирования, с помощью крошечного лайфхака.

Итак, у нас в организации имеется несколько десятков разнотипных MSSQLSERVER, разных редакций. Express превалирует, но это – не важно. Инфраструктура – старая, целиком унаследованная, и — «кусочно-непрерывная».

Задача: «запустить один и тот же запрос/пакет на нескольких серверах в нескольких базах данных», у нас, что называется, «редко бывает, но часто случается».

И то, что это «редко бывает» — не позволяет изобрести достойного обоснования для закупки или написания полноценного софта для централизованного администрирования всего зоопарка, а то, что «часто случается» — бывает, требует мгновенного решения в стиле «5 секунд до взрыва».

Но всё это – лирическое отступление, дисклаймер и всё такое.

Когда много лет подряд Microsoft лихорадит из одной крайности в другую, то понемногу начинаешь привыкать к этому и все новое ждешь с неким скепсисом. Со временем это чувство становится только сильнее и подсознательно ничего хорошего уже не ожидаешь.

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

Такое пафосное вступление имеет определенные на то основания, поскольку долгое время на Microsoft Connect поддержка работы с JSON на SQL Server была одной из самых востребованных фич. Шли годы и неожиданно данный функционал реализовали вместе с релизом SQL Server 2016. Забегая вперед скажу, что вышло очень даже хорошо, но Microsoft не остановилась на этом и в SQL Server 2017 существенно улучшили производительность и без того быстрого JSON парсера.

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

Возможно, многие сталкивались с исторически сложившейся за годы, до появления на проекте, ситуацией, когда на таблице создали все возможные индексы со всеми include’ами. Я видела индекс на доставшейся «в наследство» БД, который содержал все поля таблицы. При этом, не всегда есть возможность быстро поменять индексы, так как часто нужна гарантия, что изменения не повлияют на работоспособность системы.

При росте объема таблицы становится мучительно больно за бесцельно занятое место, но просто так индекс уже не убьешь, а статистика использования показывает, что индекс используется.
Описаный пример консолидации индексов на высоконагруженной БД, работающей в режиме 24/7. Приложение использует только хранимые процедуры. Версия MS SQL Server 2012 SP3.

Привет! DataGrip замыкает цепочку релизов наших IDE, хотя вы уже могли попробовать то, о чём я расскажу, в других продуктах: поддержка баз данных есть во всех наших IDE, кроме WebStorm (потому что он дешевле), CLion и AppCode (потому что не просят).

Предисловие

В Интернете можно найти достаточно много примеров по созданию резервных копий баз данных, а также по их восстановлению. Приведем еще один пример встроенными средствами в MS SQL Server.

В данном примере будут собраны сразу несколько подходов-от проверки целостности базы данных перед созданием резервной копии до восстановления этой базы по уже созданной ранее резервной копии.

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

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

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

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

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

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

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

Привет, Хабр! Такое понятие, как «Глубокое обучение», существует с 1986 года, когда его впервые употребила Рина Дехтер. Развитие технология получила в 2006 после выхода публикации Джеффри Хинтона об эффективном предобучении многослойной нейронной сети. Сегодня deep learning часто живет в связке с распознаванием речи, пониманием языка и компьютерным зрением. Под катом вы узнаете про использование алгоритмов глубокого обучения в SQL. Заглядывайте!

У одного из наших достаточно крупных клиентов, в системе электронного документооборота которого ежедневно одновременно работают более 10000 пользователей, были применены так называемые sparse-колонки или разреженные столбцы.

Статья – попытка свести предпосылки и результаты применения этой функциональности (и некоторых других настроек СУБД) в едином месте.

Предисловие

Часто возникает потребность в создании такого индикатора производительности, который бы показывал состояние СУБД относительно предыдущего периода или конкретного дня. В статье Реализация индикатора производительности запросов, хранимых процедур и триггеров в MS SQL Server. Автотрассировка был предложен пример по реализации такого индикатора. Здесь же опишем еще один более простой способ, который ко всему прочему позволяет посмотреть исторически не просто за сколько выполнился запрос, но и как выполнился, а также получить планы выполнения на каждый момент времени.

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

В данной статье будет рассмотрен пример реализации такого общего индикатора, где в качестве меры будет браться все время выполнения запросов (Total Elapsed Time).

Опережающий рост значимости информационной части систем по сравнению с собственно вычислительной составляющей – одна из ключевых тенденций развития ИТ. Чтобы понять правильность этого тезиса совсем не обязательно прибегать к ссылкам на авторитетные аналитические исследования, достаточно просто обратиться к собственному опыту. Компании уже давно поняли, что информация является не просто инструментом для поддержки своей оперативной деятельности, но и становится все более важным для нее активом, в существенной мере обеспечивающим не только повышение капитализации компании, но и ее успешного развития в будущем. Цифровая трансформация, которая затрагивает все уровни современного общества от частного пользователя до государства, в основе своей базируется на базовом тезисе «деятельность на основе данных».

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

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

Предисловие

Достаточно нередко можно встретить задачу об обеспечении отказоустойчивости СУБД MS SQL Server. Еще интереснее становится, когда нет лицензии Enterprise, а только Standard.

Сразу отметим, что рассматриваться лицензия Express не будет, т к по данному экземпляру есть существенные ограничения. Да, некоторые из них можно обойти. Например, максимальный размер БД в 10 ГБ легко решается путем декомпозиции большой БД на более маленькие (например, по какому-то признаку создавать новую БД, а в главной БД в представлениях объединять выборки из одних таблиц разных БД). Но отказоустойчивость в Express будет достигаться либо силами системного администратора, либо использованием собственно разработанного (или стороннего) ПО.

В данной статье будут вкратце разобраны все существующие стандартные технологии отказоустойчивости для MS SQL Server 2017 и будет рассмотрен пример реализации отказа наиболее подходящего унифицированного из них в лицензии Standard.

Продуктами 2ГИС пользуются 30 млн горожан. Чтобы огромный набор данных попал к конечному пользователю, мы используем множество внутренних продуктов, о которых очень редко рассказываем.

Однажды на Хабре уже была статья о нашем внутреннем продукте — векторном редакторе геометрий. Чудеса нейминга привели нас к трём точкам — Fiji. До них проект назывался так: «Новая карта» → «Новая новая карта» → «Новая новая новая карта». Три года назад мы приступили к реализации Fiji и рассказали о прототипировании UI, сегодня — погрузимся в технические детали и расскажем о том, как создать быстрый и надежный ГИС-редактор.

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

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

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

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