Ограничения таблиц

{ "title": "Ограничения таблиц в Delphi: сравнение CHECK, UNIQUE, NOT NULL и альтернатив", "keywords": "Delphi, ограничения таблиц, CHECK, UNIQUE, NOT NULL, сравнение, альтернативы, выбор, SQL, базы данных", "description": "Подробное сравнение и выбор ограничений таблиц в Delphi: CHECK vs триггеры, UNIQUE vs индексы, NOT NULL vs домены. Таблица характеристик и рекомендации, кому какой вариант подходит.", "html_content": "

Ограничения таблиц в Delphi: выбор между CHECK, UNIQUE, NOT NULL и их заменителями

При работе с базами данных из Delphi разработчик неизбежно сталкивается с задачей контроля целостности данных. В отличие от «универсального» подхода, когда все проверки складывают в прикладной код, использование декларативных ограничений SQL имеет чёткие границы применимости. Ниже — сравнение трёх классических ограничений (CHECK, UNIQUE, NOT NULL) с их альтернативами, чтобы вы могли осознанно выбрать стратегию для конкретного проекта.

CHECK vs триггеры BEFORE INSERT/UPDATE: что выбрать?

CHECK-ограничение — декларативная проверка на уровне столбца или таблицы. Триггер — процедурная логика, срабатывающая до записи.

• CHECK проще и быстрее проверяется ядром СУБД, не нуждается в коде на Delphi или SQL-скрипте поддержки. Подходит, когда условие статично: например, цена товара не может быть отрицательной, дата рождения не должна быть в будущем. Не подходит, если проверка требует выборки из других таблиц, вызова хранимых функций или сложной логики с ветвлениями — тогда CHECK станет узким местом или вовсе не поддерживает внешний контекст.
• Триггер даёт гибкость: можно проверить сложные бизнес-правила, записать логику, откатить транзакцию. Кому подходит: разработчикам, работающим с изменяющимися требованиями, или когда проверка затрагивает связанные таблицы. Минус: триггеры замедляют массовые вставки, их сложнее отлаживать и переносить между СУБД (особенно если проект на Delphi использует несколько видов SQL-серверов).

Итоговый выбор: для простых проверок одного поля — CHECK (меньше кода, выше скорость). Для кросс-табличных или условных проверок — триггер. Если проект на Delphi мигрирует между СУБД, отдайте предпочтение триггерам на стороне приложения.

UNIQUE vs уникальный индекс: скрытые различия

На первый взгляд, UNIQUE-ограничение и уникальный индекс делают одно и то же — не допускают дубликатов. Но разница есть.

• UNIQUE — это логическое ограничение целостности. В некоторых СУБД (например, Firebird) оно автоматически создаёт индекс, но его можно отключить. Подходит: когда нужно явно документировать бизнес-правило (у каждого клиента уникальный email). Не подходит: если вы хотите управлять типом индекса (например, сортировка по убыванию для частичного уникального ключа).
• Уникальный индекс — физическая структура, гарантирующая уникальность, но не выраженная в метаданных как ограничение. Кому подходит: разработчикам, управляющим производительностью — можно задать кластеризованный или покрывающий индекс. Не подходит, если вы используете генераторы ORM, которые сканируют словарь ограничений — они могут не увидеть индекс.

Выбор: В Delphi-приложениях с прямым SQL чаще используйте UNIQUE — оно читаемее и поддерживается DbGrid, мастером импорта данных. Если ключ композитный с нестандартной сортировкой — уникальный индекс.

NOT NULL vs домен (user-defined type) с проверкой: производительность vs гибкость

NOT NULL — самый простой способ запретить NULL в столбце. Домен — пользовательский тип данных, который может включать NOT NULL + допустимые значения.

• NOT NULL — единичное условие, не влияет на производительность при вставке. Подходит: для первичных ключей, внешних ключей, полей, где NULL не имеет смысла (например, поле ID клиента). Не подходит: когда правило «не пусто» распространяется на множество столбцов или нужно ещё и ограничить диапазон значений (например, «поле может быть только 1, 2, 3»). Тогда NOT NULL не решит все задачи.
• Домен позволяет собрать все ограничения на тип вместе (NOT NULL + CHECK). В Delphi с Firebird или InterBase это удобно для переиспользования. Кому подходит: командам, где приложение общается с БД через слои — изменение домена сразу применяется ко всем таблицам. Не подходит: при использовании BDE или dbGo напрямую — трансляция доменов не всегда корректна.

Сравнение: если у вас одно поле — NOT NULL быстрее и проще. Если набор правил повторяется (например, статус документа всегда 0, 1 или 2 и не NULL) — домен сокращает SQL-код и уменьшает ошибки.

Таблица сравнения характеристик

Для быстрой оценки — сводка по ключевым параметрам:

• Скорость проверки: CHECK / NOT NULL — высокая (на уровне блока данных); триггер — средняя (на каждую строку); UNIQUE — зависит от индекса.
• Гибкость: триггеры > домены > UNIQUE > CHECK > NOT NULL.
• Переносимость между СУБД: NOT NULL и UNIQUE — полная; CHECK — с оговорками (разный синтаксис логических функций); триггеры — минимальная (диалекты PL/SQL различаются).
• Удобство для Delphi-кода: домены и NOT NULL автоматически подтягиваются в dbExpress или FireDAC; триггеры — прозрачны, но не отображаются в метаданных.
• Риск ошибок бизнес-логики: минимален при CHECK/UNIQUE/NOT NULL; средний у триггеров (легко пропустить кейс), высокий — если часть правил на Delphi (можно забыть вызвать метод).

Рекомендация: В типовом Delphi-проекте сочетайте CHECK для полей с фиксированными диапазонами, UNIQUE для бизнес-ключей, NOT NULL для обязательных столбцов. Триггеры оставьте для аудита или сложных проверок, которые нельзя выразить иначе. Домены — если точно знаете, что в будущем не придётся менять СУБД на менее поддерживающую пользовательские типы.

" }

Добавлено: 27.04.2026