Microsoft SQL Server *

Мне всегда было интересно (и не только мне) есть ли смысл запуска 1С в диске из оперативной памяти, потому что если посмотреть на графики скорости чтения различных типов накопителей, то преимущества  очевидны:

В мире кровавого энтерпрайза есть некоторое количество проектов-мамонтов. Они большие, у них базы данных на SQL Server, в этих базах тысячи и десятки тысяч объектов, миллионы строк кода T-SQL, огромная вариативность данных, всё хрупкое, неидемпотентное, недетерминированное и фигово документированное. Короче, как писал Roy Osherove в своей The art of unit-testing:

Finally, as a friend once said, a good bottle of vodka never hurts when dealing with legacy code.

В вольном переводе "Да там без поллитры не разберёшься!"

И вот у этих проектов есть беда — большие контуры тестирования и разработки, часто так или иначе модифицированные и уменьшенные копии основного продуктового контура. Да-да-да, тут сразу поналетят умные да в белой одежде и начнут объяснять, что надо писать тестовые наборы данных (а кто спорит?), что тестовый контур должен быть небольшим (а кто спорит?), что код должен быть переносимым между СУБД (спасибо, Кэп!), что всё было бы лучше, если бы проект переписали N лет назад (ха-ха) и прочие "станьте ёжиками" и "пусть едят пирожные". Нет, дорогие мои. Просто представьте, что у вас есть БД SQL Server с 25К объектов (таблиц и ХП) и миллионами строк запросов, и часть объектов создана с SET ANSI NULLS ON, а часть с SET ANSI NULLS OFF. И точно известно, что в части запросов эта разница используется. И БД на дестяки ТиБ. И однодневный простой системы стоит больше, чем квартиры всех разработчиков, которые за последние 20 лет трогали этот код (из которых, кстати, сейчас работает только 7 последних самураев). Одно это может не давать перейти с SQL Server 2008 R2 на что-то более свежее пару лет.

Большие объемы данных вынуждают глубже смотреть в логику работы оптимизатора СУБД. Ваше понимание о выборе селективного индекса может расходится с логикой выбора оптимизатора SQL. Это еще больше привязывает конкретную систему к конкретной СУБД. Построение хорошего запроса к СУБД попрежнему остается искусством, а искусственный интеллект пока еще туда не добрался. Кто больше виноват - 1С или MS SQL - решать Вам.

Рассматривая планы запроса для INSERT, UPDATE или DELETE, в том числе те, которые демонстрировались в некоторых статьях ранее, можно заметить, что почти все такие планы включают оператора TOP. 

Посвящается тем, кому надоело писать один и тот же SELECT в SSMS

Настраиваем горячие клавиши для сниппетов.

Почему при росте объемов базы 1С все становится медленней, даже если все индексы правильно сделаны? В статье на простом примере с регистром сведений показана причина и как этого избежать. Кто виноват больше 1С или MS SQL решать Вам :)

По белой книге Адаптация Алексеев Денис делается последнее поколение приставок RyBox. С Романом Душкиным мы работаем над тем, что мы обретём Сильное Бессмертие благодаря внедрению Метода тотального контроля (МТК -8) отличающийся от МТК 6 и 7 наличием показателя УЦД(уникальность цифрового двойника).
Метод тотального контроля (МТК6):

I. Наблюдение как система выполняет операции

II. Тестирование и постоянное обновление

III.Определение тенденций развития

IV.Детальный анализ данных на выходе

V. Написание отчёта о результатах

VI.Завершающий диалог с системой

VII. Тестирование

(МТК ЭиО)

Анализ теста Сотрудника

Обновление ИОТ/(база знаний)

Определение тенденций развития Руководителем

Детальный анализ Ментором работы Сотрудника

Написание отчёта о результатах

Завершающий диалог с Сотрудником

Тестирование подготовки Сотрудника Отделом Качества

Э- эксперт
О- обучающийся
ИОТ - индивидуальная образовательная траектория

И так резюмируем какие МТК кого контролируют
Метод Тотального Контроля 6 - Роботы
Метод Тотального Контроля 7 - Люди
Метод Тотального Контроля 8 - Цифровые Двойники
Метод Тотального Контроля 9 - Клоны
Благодаря Клонам мы приближаемся к Сильному бессмертию

МТК Х - волшебники.

В продолжение статей Приключения при настройке сервисов машинного обучения в MS SQL Server 2019 и Используем R lang в SQL Server разбираемся как работать с Python в сервисам машинного обучения. С Python ситуация несколько лучше, чем с R, так как достаточно много предустановленных библиотек и версия Python не так сильно отстает от актуальной, как в случае с R.

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

Для разбора примеров используется созданная в статье про R база данных с датасетом из соревнования Kaggle Титаник.

Оператор UNPIVOT по смыслу противоположен оператору PIVOT. Как было описано в предыдущей статье, оператор PIVOT преобразует нормализованную таблицу в таблицу, у которой столбцами являются значения в исходной таблице. Оператор UNPIVOT берет сводную таблицу и преобразует ее обратно к нормализованной форме с одной строкой на запись данных, используя в результате имена столбцов в качестве значений.

Workaround свидетельствует о невозможности решить проблему "правильным путем" и вызывает чувство стыда. Но практика показывает, что способность решать проблемы через workaround является порой единственным способом решить проблему в разумное время. А победителей, как говорят, не судят, так почему бы создавать workaround по науке?

В продолжение предыдущей статьи поговорим о том, как использовать SQL Server Machine Learning Services. В этой статье приведены варианты использования на языке R. 

Для чего должна быть установлена R 4.2.1(https://cran.r-project.org/src/base/R-4/) 

Также нам потребуется пакет randomForest, его можно установить в студии (меню) Пакеты -> Установить пакет .Если же у вас тоже windows и это не будет работать как и у меня, скачивайте пакет c CRAN и выбирайте Пакеты -> Установить пакеты из локальных файлов, а затем скаченный архив. 

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

Для знакомства с возможностями SQL Server в машинном обучении используется датасет с пассажирами Титаника с Kaggle

Всем привет.

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

По материалам статьи Craig Freedman: PIVOT Query Plans

В предыдущей статье был дан обзор оператора PIVOT. В этой статье рассмотрим планы запросов при использовании оператора PIVOT. Как мы далее увидим, SQL Server создаёт простой план запроса, который, по сути, представляет собой вариацию плана с агрегацией.

Механизм общих реквизитов разделителей 1С создает излишнюю\негативную нагрузку на структуру базы данных, но еще больше проблем доставляет при использовании временных таблиц.

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

В статье описано, как настроить сервисы машинного обучения для R и Python. Несмотря на большой опыт в IT, сразу у меня не работает примерно ничего. Поэтому будут ссылки на то, что делать, если сразу не завелось. В итоге я поставила новый экземпляр с сервисами машинного обучения, которые, наконец! заработали. 

Недавно нам прилетело большое тестовое задание от Тиньков-Банка на должность аналитика данных. Там очень много задач, но сегодня мы разберем несколько — остановимся на мелочах и обратим внимание на тонкие моменты.

И, конечно, попишем SQL-запросы!

Удаление архивных данных из базы это непростая задача как в 1С так и для любой базы данных. В статье изложены различные способы решения задачи, включая самый эффективный для 1С

Entity Framework — это удобный фреймворк для работы .NET-приложения с базой данных. По сути, это такая удобная абстракция над БД, которая сама пишет за разработчика оптимальные (ну, почти) SQL-запросы прямо из высокоуровневых LINQ-конструкций. Одной из киллер-фич фреймворка является возможность относительно легко сменить СУБД приложения на какую-нибудь другую. Предположим, разочаровались вы в MySQL или, наоборот, хотите сменить MSSQL на что-то менее дорогое — пожалуйста, EF как абстракция над СУБД в теории может это предоставить, так сказать, by design.

Проблема в том, что в мире бизнес-разработки СУБД меняют лишь по очень большой нужде, а потому редко кто уже сталкивался с данной фичей EF на практике, но вот мне такая возможность выпала. Поэтому я решил написать небольшой гайд, как это выглядит в реальности, чтобы у вас была возможность оценить применимость данной фичи, если вдруг это понадобится.