SQL-Ex blog - T-SQL

T-SQL в SQL Server 2025: нечеткий поиск строки II

nospam@example.com (Sergey Moiseenko) — Fri, 13 Mar 2026 08:40:00 +0300

Пересказ статьи Steve Jones. T-SQL in SQL Server 2025: Fuzzy String Search II

В последней статье мы проверяли нечеткое соответствие строк при помощи новых функций в SQL Server 2025. Мы знаем, что сравнение строк всегда вызывало сложности, когда у нас нет качественных данных. Если нам нужно точное совпадение, SQL Server работает отлично. Однако мы часто ждем от пользователей ввода значений без опечаток и знать, какие значения они хотят найти. Или хотя бы знать часть строки.

В SQL Server 2025 появилось несколько новых функций, которые помогают с нечетким совпадением строк. В последней статье были рассмотрены функции расстояния, EDIT_DISTANCE() и EDIT_DISTANCE_SIMILARITY(). В этой статье мы проверим две другие функции, JARO_WINKLER_DISTANCE() и JARO_WINKLER_SIMILARITY(). Как и другие функции, они находятся в предварительной версии (по состоянию на январь 2026 г.), так что будьте осторожны с использованием их в продакшене. Вам также необходимо включить эти функции как часть конфигурации области базы данных. Мы рассмотрели это в первой статье.

Это часть серии статей, посвященной тому, как язык T-SQL развивается в SQL Server 2025.

Примечание. Некоторые из этих изменений уже доступны в различных продуктах Azure SQL.
Continue reading "T-SQL в SQL Server 2025: нечеткий поиск строки II"

Общие проблемы в SQL Server: Invalid Length

nospam@example.com (Sergey Moiseenko) — Mon, 09 Mar 2026 15:48:00 +0300

Пересказ статьи Aaron Bertrand. Common SQL Server Problems: Invalid Length

Это еще одна часть моей серии, представляющей общие проблемы в SQL Server. Сейчас мы поговорим о самой распространенной ошибке: invalid length (неверная длина).

Что означает ошибка invalid length в SQL Server?

Msg 537, Level 16, State 3

Invalid length parameter passed to the LEFT or SUBSTRING function.

Как показано выше, ошибка invalid length возникает, когда вы передаете некорректный или неожиданный параметр в строковую функцию. Например:

DECLARE @FirstName nvarchar(32) = N'frank';

SELECT LEFT(@FirstName, -1);

Continue reading "Общие проблемы в SQL Server: Invalid Length"

Таблицы UNLOGGED в PostgreSQL: когда скорость важнее надежности

nospam@example.com (Sergey Moiseenko) — Wed, 04 Mar 2026 08:50:00 +0300

Пересказ статьи Chandan Shukla. UNLOGGED Tables in PostgreSQL When Speed Matters More Than Durability

Введение

Каждая реляционная база данных живет и умирает благодаря своему журналу транзакций. В SQL Server это файл журнала транзакций, в PostgreSQL это WAL (Write-Ahead Log - записывай сначала в журнал). Это работающее сердце, которое гарантирует надежность хранения, восстановление и репликацию. Без журнала вы не смогли бы обеспечить согласованность после сбоя, восстановить базу к определенному моменту времени или иметь надежные реплики.

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

PostgreSQL дает вам именно такую возможность посредством таблиц UNLOGGED (нежурнализируемых). Это функция, которая меняет сценарий: таблица по-прежнему сохраняется на диске, но ее записи не попадают в WAL. Это означает существенно меньше накладных расходов, зачастую значительно более быстрые массовые операции, но при большом недостатке - ненадежность при сбоях базы данных.

Для администраторов SQL Server это кажется странным. У нас нет подобной функции «один в один». Вы можете подумать о BULK INSERT с минимальной журнализацией, временных таблицах в tempdb или даже об оптимизированных для памяти таблицах SCHEMA_ONLY. Каждый из этих случаев имеет кусочек от поведения UNLOGGED, но не все целиком.

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

Continue reading "Таблицы UNLOGGED в PostgreSQL: когда скорость важнее надежности"

Теория множеств и пакетный режим в SQL Server

nospam@example.com (Sergey Moiseenko) — Sun, 01 Mar 2026 23:52:00 +0300

Пересказ статьи SQLPals. Set Theory vs. Batch Mode in SQL Server

Не так давно коллега был в совершенном шоке, когда впервые услышал о возможности пакетного режима в SQL Server. Его мгновенной реакцией было: "Стой, но SQL основан на теории множеств. Не означает ли это, что он уже все обрабатывает как множество, а не построчно?"

Это действительно довольно общее представление, и на первый взгляд это имеет смысл. Кроме того, люди часто представляют силу реляционных баз данных в том, что они "обрабатывают множества данных за один прием". Однако есть нюансы. Давайте проясним ситуацию. Continue reading "Теория множеств и пакетный режим в SQL Server"

Предложение VALUES или создание таблиц из ничего

nospam@example.com (mssqlhelp) — Mon, 16 Feb 2026 18:08:00 +0300

Автор: Joe Celko, The VALUES clause or building tables out of nothing

Предложение VALUES, вероятно, одна из самых неправильно используемых возможностей в SQL. Если вы посмотрите на онлайн-форумы по SQL, вы увидите, что люди используют его как второе предложение в операторе вставки, но используют его для построения только одной строки за раз, например так:

BEGIN

INSERT INTO Zodiac (astro_sign, astro_start_date, astro_end_date)

 VALUES ('Aries', '2025-03-21', '2025-04-19');

INSERT INTO Zodiac (astro_sign, astro_start_date, astro_end_date)

 VALUES ('Taurus', '2025-04-20', '2025-05-20');

… 

INSERT INTO Zodiac (astro_sign, astro_start_date, astro_end_date)

 VALUES ('Pisces', '2023-05-19', '2026-03-20');

END;

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

Я думаю, люди пишут такой код, потому что именно так вы бы читали перфокарты. Каждая карта поступает в устройство чтения карт, буферизуется и записывается в порядке поступления на магнитную ленту или дисковый файл. Добро пожаловать в 1960-е! Перестаньте подражать старым языкам программирования, таким как FORTRAN или BASIC, в которых были операторы WRITE, помещающие по одной записи за раз в файл. Начните думать о работе с целыми множествами.

Continue reading "Предложение VALUES или создание таблиц из ничего"

T-SQL в SQL Server 2025: конкатенация строк

nospam@example.com (Sergey Moiseenko) — Fri, 13 Feb 2026 10:06:00 +0300

Пересказ статьи Steve Jones. T-SQL in SQL Server 2025: Concatenating Strings

Как и многие из вас, я часто соединяю строки (конкатенирую) при помощи простого арифметического оператора +. У нас есть еще и другие способы соединения строк, но в SQL Server 2025 появился еще один новый оператор. Это оператор двойной трубы (||). В этой статье мы разберемся, как он работает, и сравним с другими вариантами.

Новый оператор

Он действительно документирован, хотя и после || в MS Learn. Идея состоит в том, что соединяться будут: Continue reading "T-SQL в SQL Server 2025: конкатенация строк"

Эффективные стратегии для хранения и парсинга JSON в SQL Server

nospam@example.com (Sergey Moiseenko) — Sun, 08 Feb 2026 23:37:00 +0300

Пересказ статьи Edward Pollack. Effective Strategies for Storing and Parsing JSON in SQL Server

Подобно XML, JSON является открытым стандартным форматом хранения данных, метаданных, параметров или других неструктурированных или полуструктурированных данных. Из-за его активного использования в современных приложениях он обречен попасть в базы данных, где его необходимо будет хранить, сжимать, изменять, выполнять поиск и извлекать.

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

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

Значение NULL и пустая строка в Oracle, SQL Server и PostgreSQL

nospam@example.com (mssqlhelp) — Fri, 06 Feb 2026 18:36:00 +0300

Автор: Akhil Reddy Banappagari, Null and Empty String in Oracle vs SQL Server vs PostgreSQL

При планировании миграции баз данных в PostgreSQL именно мелочи часто становятся причиной самых серьёзных сбоев в рабочей среде. Одна из самых распространённых ловушек для разработчиков — это различная обработка значений NULL и пустых строк ('') в разных СУБД.

Хотя они могут казаться схожими концепциями, обозначающими отсутствие значения, то, как механизм базы данных их интерпретирует, может изменить результаты ваших запросов, нарушить уникальные ограничения или привести к сбоям загрузки данных. В этом руководстве мы сравним поведение Oracle, SQL Server и PostgreSQL, чтобы помочь вам избежать распространённых ошибок миграции.

Continue reading "Значение NULL и пустая строка в Oracle, SQL Server и PostgreSQL"

Проблема неявных транзакций

nospam@example.com (Sergey Moiseenko) — Sun, 01 Feb 2026 11:16:00 +0300

Пересказ статьи Steve Jones. The Challenge of Implicit Transactions

Сценарий

Вы выполняете такой код:

Все выглядит хорошо. Я выполнил вставку и вижу данные в таблице. Я тороплюсь, поэтому щелкаю "close" (закрыть) на вкладке и вижу это:

Я настолько привык к этим раздражающим меня сообщениям в SSMS, что я нажимаю «Нет», чтобы избавиться от них и закрыть окно.
Continue reading "Проблема неявных транзакций"

Подводные камни Truncate Table

nospam@example.com (Sergey Moiseenko) — Tue, 27 Jan 2026 09:41:00 +0300

Пересказ статьи Peter Skoglund. Truncate Table Pitfalls

Усечение таблицы может быть замечательно быстрым - и чрезвычайно опасным при неосмотрительном использовании. Если вы хотите иметь скорость и не разочароваться, тут дается практическое, готовое для интервью руководство по реальным подводным камням TRUNCATE TABLE в SQL Server и то, как избежать их.

Справка

TRUNCATE TABLE является операцией DDL, которая освобождает страницы (эффективно журнализированные) и сбрасывает IDENTITY к начальному значению. При этом триггеры DELETE не срабатывают. Возможен откат при выполнении внутри транзакции.

Завершается неудачно, если на таблицу ссылается внешний ключ (даже если дочерняя таблица пуста), используется в индексированных представлениях, является системно-версионной (временной), опубликованной для репликации или включена для CDC, или на нее ссылается ограничение EDGE графа. Существует специальная возможность для самоссылающихся внешних ключей.

Начиная с SQL Server 2016, вы можете усекать конкретные секции: TRUNCATE TABLE dbo.Fact WITH (PARTITIONS (4 TO 6)); (индексы должны быть выровнены).

Continue reading "Подводные камни Truncate Table"

Массовая вставка T‑SQL или OPENROWSET: импорт CSV, проблемы доступа к файлам и скрипт PowerShell

nospam@example.com (Sergey Moiseenko) — Sun, 18 Jan 2026 16:43:00 +0300

Пересказ статьи Rick Dobson. T‑SQL BULK INSERT vs OPENROWSET: CSV Imports, File Access Gotchas, and A PowerShell Script

Большинство руководств по массовой вставке SQL и SQL Server openrowset игнорируют проблемы доступа к файлам, которые могут прервать импорт. И оператор bulk insert, и функция openrowset выполняются под аккаунтом службы SQL Server при чтении файла источника. Аккаунт службы SQL Server должен иметь разрешение на чтение файла или папки, где файл находится. Также удобно иметь разрешения на чтение и выполнение, а также вывод содержимого папки. Кроме того, нестандартные места размещения файла источника (например, C:\Users\Public\Downloads) могут не предоставлять доступ на чтение по умолчанию аккаунту службы SQL Server - всегда проверяйте это перед использованием.

Импорт данных из файла источника в таблицу SQL Server является обычной операцией, но она озадачивает многих новичков и порой вызывает трудности даже у опытных разработчиков в сложных сценариях. В этой статье изучается импорт файлов CSV в таблицы SQL Server либо с помощью оператора BULK INSERT, либо функции openrowset в операторе SELECT. Continue reading "Массовая вставка T‑SQL или OPENROWSET: импорт CSV, проблемы доступа к файлам и скрипт PowerShell"

Что использовать: VARCHAR или NVARCHAR?

nospam@example.com (Sergey Moiseenko) — Mon, 22 Dec 2025 19:20:00 +0300

Пересказ статьи Brent Ozar. Which Should You Use VARCHAR or NVARCHAR?

Вы строите новую таблицу или добавляете столбец, и вы хотите знать, какой тип данных использовать: VARCHAR или NVARCHAR?

Если вам необходимо хранить данные Unicode, выбор сделан за вас: NVARCHAR говорит, что это буду я.

Но если вы не уверены, то можете подумать: "Я должен использовать VARCHAR, поскольку он занимает вдвое меньше места". Я это знаю, потому что чувствовал то же самое, но множество комментаторов указали мне на это, когда я опубликовал ответ в «Office Hours» о том, что по умолчанию я использую VARCHAR. Один за другим разработчики говорили мне, что я неправ и что в 2025 пришло время вместо этого по умолчанию использовать NVARCHAR. Давайте проведем эксперимент!

Чтобы выяснить это, давайте возьмем большую базу данных Stack Overflow и создадим две копии таблицы Users. Я использую здесь таблицу Users, чтобы сделать демонстрацию краткой и понятной, поскольку у меня нет возможности целый день загружать гигабайты данных (и перезагружаться, как вы сейчас увидите). Мы просто собираемся сфокусироваться на строковых столбцах, поэтому я создал одну с типами VARCHAR, а другую - с NVARCHAR. Затем для простоты мы загрузим только те данные, которые являются чисто VARCHAR (потому что некоторые чудаки могли добавить какие-нибудь необычные данные Unicode в столбец AboutMe).
Continue reading "Что использовать: VARCHAR или NVARCHAR?"

Сравнение перестройки и реорганизации индексов SQL

nospam@example.com (Sergey Moiseenko) — Wed, 17 Dec 2025 23:10:00 +0300

Пересказ статьи Sergey Gigoyan. SQL Index Rebuild vs Reorganize Comparison

При модификации данных в базе данных SQL соответствующие индексы тоже изменяются. Эти изменения приводят к фрагментации индексов. Фрагментация означает, что логический порядок данных на страницах индекса не соответствует физическому порядку. Во фрагментированных индексах информация не располагается логически, что делает операции извлечения данных из индекса более затратными по времени, это приводит к проблемам производительности запросов. Таким образом, фрагментацию индексов следует периодически устранять для поддержания высокой производительности. Операции перестройки и реорганизации индекса как раз направлены на дефрагментацию индексов.

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

Continue reading "Сравнение перестройки и реорганизации индексов SQL"