Microsoft SQL Server *

NAS Колхозника-1Сника на базе Turbo Селерона N150 и под управлением MS Server 2019 в компактном корпусе и с надеждой на надежность.

В этой статье я расскажу как я использовал новейшие возможности ИИ MSSQL 2025 для поиска гостендеров. Текущую рабочую версию я выложил на https://artemtender.ru

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

Оказалось что на zakupki.gos.ru найти что-то не реально. Там нет нормального фильтра, нужно вручную просматривать сотни позиций, и то позиция может выглядеть просто как "Разработка и поставка ПО". Дальше нужно скачивать документацию вручную и читать. Первая мысль - нужно скармливать Chat GPT и спрашивать подходит ли заказ лично мне. С этим он справляется неплохо, но нужно в начале эту позицию найти, а с этим он уже не справится.

Решение следующее - необходимо зарегистрироваться в системе госзакупок и получить токен на получение данных. Для поиска позиций я использую косинусную сходимость. Тут очень пригодился новый тип Vector в MSSQL. В базе он выглядит так: [Vector] vec NULL. Этот тип уже поддерживается новейшим EF Core. Все названия закупок индексируются помощью модели ai-forever/ru-en-RoSBERTa методом проб и ошибок я выбрал ее. Подскажите в комментариях, может быть есть что то и лучше. Микросервис на пайтоне получает batch запрос на индексацию и через RabbitMQ возвращает в микросервис обработки БД на .NET Core. В профиле пользователь создает товары и услуги которые так же индексируются через поле Vector. Поиск и сравнение идет уже средствами самого MSSQL и в результате все работает довольно быстро. Скан нескольких сотен тысяч позиций происходит в реальном времени. Единственно, сама индексация не столь быстрая, поэтому я вынес в профиль. Кроме того, по моему это просто удобно - ведь твои услуги меняются не так часто и их проще выбрать из списка. В моем веб-приложении https://artemtener.ru это выглядит так:

Всем привет! Меня зовут Александр Гаврилов, я архитектор баз данных и аналитических систем в GRI. Если вы когда-нибудь пытались выполнить одну и ту же операцию с похожими таблицами в разных базах, да ещё и на разных серверах, то знаете, насколько это может быть мучительно.

В этой статье я покажу один из рабочих вариантов, как упростить такую задачу, и заодно расскажу про интересную функцию XQuery, которая может неожиданно помочь.

Переходим к заключительной третьей части регламентного обслуживания баз данных. И сегодня акцент сделаем на обслуживании статистик в СУБД PostgreSQL. Актуальные статистики в PG важны ничуть не менее, чем в MS SQL, но разница в настройках и алгоритмах есть, соответственно, подходы будут чуть различаться.

На просторах интернета легко можно найти материалы по реализации нечёткого поиска, в которых предполагается поиск одной строки в множестве строк M. Но что если возникнет необходимость реализовать нечёткое сравнение множества M₁ с множеством M₂? При классическом подходе нам придется выполнить сравнений - при линейном росте этих множеств, сложность задачи будет расти экспоненциально, в плане производительности это решение никуда не годиться!
В этой статье предложен вариант реализации ускоренного алгоритма для решения этой задачи. Теоретической новизны в проекте практически нет. Цели:
1 - Ознакомить с концепцией
2 - Дать конкретный пример интеграции в БД SQL(MSSQL)
3 - Ознакомить с возможностями на базе практической реализации

В предыдущей статье обсуждали регламентное обслуживание с акцентом на пересчет статистик. Операция крайне полезная, необходимая и чем интенсивнее меняются данные в базе, тем важнее актуальные статистики. Сегодня поговорим про еще одну регламентную операцию – пересчет индексов. Как всегда с акцентом на высоконагруженные системы 1С.

"Нужно?", "Не нужно?", "А если у меня SSD-диск?", "А какой эффект от перестроения индексов?", "А я не успеваю за ночь. Что делать?"

Разберем подробно все нюансы.

Создаем песочницу для безопасного выполнения non-trusted DSQL-кода и возвращаем из него by design безопасный результат в высокопривилегированное кольцо

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

Сегодня хочу затронуть тему регламентного обслуживания баз данных MS SQL. А позже поговорим и про обслуживание баз PostgreSQL.

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

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

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

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

Для чего используют кластеризацию серверов СУБД? Вопрос не совсем праздный, особенно для крупных компаний. Если с кластеризацией/масштабированием серверов приложений, терминалов, web-серверов и т. д. все понятно и прозрачно, то вот с СУБД не всё так просто. Особенно для 1С систем.

Слой приложения persistence layer является в определённом смысле уникальным в смысле узкой направленности его функционала по сравнению с другими слоями приложения. Если рассматривать его только для работы с реляционными базами данных, то реализацию функционала слоя можно разбить на два основных варианта - с использованием ORM фреймворка и без использования ORM фреймворка. Каждый из этих вариантов можно реализовать достаточно универсальным образом.

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

Можно ли хранить данные, строить по ним отчетность, при этом обходясь без ETL процессов? Технически — да. Практически — только до первого серьезного роста данных.

Привет, Хабр! Меня зовут Алина, и в этой статье я расскажу о критически важном этапе, через который проходит любая data-driven компания.

Речь о переходе:
от построения отчетности напрямую из операционных баз (или через примитивное копирование в STG)
к структурированным ETL-процессам на специализированном ПО.

В нашем случае этим ПО стал SSIS — но важно подчеркнуть: сейчас мы используем NiFi с [N] процессорами для управления data pipeline. Однако именно опыт с SSIS стал для нас тем самым «мостиком» между хаотичным и осознанным подходом к данным.

P.S. Если хотите узнать про то, как мы организовали работу в NiFi — пишите в комментах, сделаем отдельный материал!

В этой статье — только про этап с SSIS. Не потому что он «лучший», а потому что:

Тема перехода на PostgreSQL весьма популярна, и почти на каждой конференции по PG обязательно есть парочка докладов на эту тему. Почему же эта тема до сих пор злободневна?

Когда мы начинали свой блог здесь на Хабре, наша первая статья была посвящена как раз задаче перевода больших баз данных MSSQL –> PostgreSQL. И первой причиной, из-за которой компании решаются на переход мы называли законодательство. А именно, необходимость для государственных и окологосударственных организаций, чьи информационные системы относятся к значимым объектам критической информационной инфраструктуры (ЗОКИИ) переводить свою работу на отечественное ПО. Прошло два года. И это всё еще основная причина.

Это не будет инструкция в стиле «делай раз», «делай два». Это будет про то, что большие базы в принципе очень тяжело и рискованно передвинуть (СУБД, платформа, окружение,…). И мы предлагаем собственный метод, как это сделать с гарантией отсутствия простоев бизнеса. Даже если что-то пойдет не так в «новой» системе, пользователи не должны страдать, а бизнес простаивать. Это главное!

KafkaRail гудел на фоне.

Паб The Broken Tag, где начиналось утро героев, только просыпался — запах старого эля, крошки лог‑файлов, и бильярдный стол под тусклым светом прожектора. Через узел маршрута /corp/news метропоезд пронёсся, как push‑уведомление на рассвете. День в Киберляндии начинался.

JSON откинул капюшон куртки BitStone Protocol с QR‑патчем на рукаве, кивнул Mr. Parseley и заказал, как обычно, Schema Fresca. Он прошёл к бильярдному столу английского пула, стоявшему под старым плакатом «Keep Calm and Close Tags», где RAMmy спорил с TryCatch о синтаксисе ударов.

В статье подробно разбирается план выполнения запроса с оконной функцией в MS SQL Server, проводится сравнительный тест производительности с альтернативным запросом.

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

Секретное оружие в .NET Core: Почему вы игнорируете мощь T-SQL?

Ваши LINQ-запросы становятся громоздкими? Производительность упирается в потолок? Возможно, вы упускаете нечто важное.

Эта статья — приглашение взглянуть на привычные инструменты под новым углом. Мы исследуем гибридный подход, который позволяет использовать весь потенциал Microsoft SQL Server, выходя за рамки стандартного взаимодействия через EF Core. Узнайте, как T-SQL может упростить сложные задачи, повысить производительность и сделать вашу архитектуру более гибкой.

Это не просто технический трюк, а переосмысление роли СУБД в современном приложении. Готовы узнать, как использовать "скрытые" возможности MSSQL и почему это может быть именно то, что нужно вашему проекту?

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

Назвать ту работу — работой мечты, сложно, как ни крути. Трудозатраты на сбор, обработку и визуализацию информации были так велики, что уход с работы в десять вечера был для меня настоящим праздником. Именно этот «спартанский» опыт вкупе с желанием доказать себе, что разобраться можно в чем угодно, побудил меня к изучению доселе неведомого для мира баз данных, языка запросов SQL, BI и ETL инструментов.

Как вы, возможно, уже поняли, в аналитику я попал не по зову сердца, а по воле случая. Хантер Томпсон внутри меня, конечно, предпочел бы писать колонки в модные журналы, вести собственный блог о литературе или теннисе, в который я играю с детства, ну или посвятить себя еще какой-то творческой ерундистике, окрыляющей не хуже Red Bull Cola. Не смейтесь, исчезновение этого напитка с полок магазинов стало для меня в свое время настоящей трагедией.

Увы, каждый раз, находясь в поиске работы, здравый смысл неустанно напоминал мне о том, что он — главный враг творчества (Пабло Пикассо был во многом прав), а карьера фрилансера, вернее всего, приведет меня на социальное дно, нежели чем на вершину карьерной лестницы.

Итак, осознание того, что автоматизация процессов востребована на рынке и облегчает собственное существование, становится стартовой точкой долгого пути от полного непонимания азов работы с базами данных до уверенного владения всеми необходимыми инструментами для управления подразделением, обеспечивающим data-driven подход к решению задач внутри компании.

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

Далее предлагаем вашему вниманию перевод оригинальной статьи “How Many Indexes Is Too Many?”, который подготовила специалист «Автомакона». В статье детально рассматривается данная проблема и приводятся практические рекомендации по выбору подходящего количества индексов для повышения производительности.

Для начала давайте рассмотрим простой эксперимент. Возьмем популярную базу данных Stack Overflow любого размера, уберем все индексы из таблицы Users и запустим удаление одной строки командой DELETE.

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

В свете указанных обстоятельств Совет Европейского союза разработал специальный нормативно-правовой акт — Закон о цифровой операционной устойчивости (Digital Operational Resilience Act, сокращенно — DORA). Принятый в ноябре 2022 года, данный закон направлен на создание единой правовой основы, способствующей усилению защиты финансовых учреждений и иных операторов рынка от различных видов угроз, связанных с работой информационных и телекоммуникационных технологий (ИКТ).

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