Ответ
Ограничения (Constraints) — это правила, накладываемые на данные в таблицах реляционной БД для обеспечения целостности данных (data integrity). Они автоматически проверяются СУБД при операциях вставки, обновления или удаления.
Основные типы ограничений в SQL:
| Ограничение | Назначение | Пример SQL (CREATE TABLE) |
|---|---|---|
PRIMARY KEY |
Уникально идентифицирует каждую строку. Не допускает NULL и дубликаты. |
id INT PRIMARY KEY |
FOREIGN KEY |
Обеспечивает ссылочную целостность. Связывает поле с PRIMARY KEY другой таблицы. |
FOREIGN KEY (user_id) REFERENCES Users(id) |
NOT NULL |
Запрещает полю содержать значение NULL. |
name VARCHAR(100) NOT NULL |
UNIQUE |
Гарантирует, что все значения в столбце различны (допускается один NULL). |
email VARCHAR(255) UNIQUE |
CHECK |
Проверяет значение по заданному логическому условию. | age INT CHECK (age >= 18) |
DEFAULT |
Устанавливает значение по умолчанию для столбца, если оно не указано при вставке. | created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP |
Практический пример с несколькими ограничениями:
CREATE TABLE Employees (
emp_id INT PRIMARY KEY, -- Уникальный идентификатор
name VARCHAR(100) NOT NULL, -- Имя обязательно
email VARCHAR(255) UNIQUE NOT NULL, -- Уникальный и обязательный email
department_id INT, -- Может быть NULL, если сотрудник без отдела
salary DECIMAL(10,2) CHECK (salary > 0), -- Зарплата должна быть положительной
hire_date DATE DEFAULT (CURRENT_DATE), -- Дата приема по умолчанию — сегодня
FOREIGN KEY (department_id) REFERENCES Departments(id) -- Связь с таблицей отделов
);Итог: Ограничения переносят логику проверки данных с уровня приложения на уровень БД, что делает данные более надежными и согласованными.
Ответ 18+ 🔞
А, слушай, про ограничения в базах данных! Ну это ж, блядь, святое! Это как правила в твоём доме, которые не дают твоему соседу-алкашу засрать тебе холодильник пивом, а потом сказать, что это квас.
Вот представь, у тебя есть таблица, например, Сотрудники. И туда какой-нибудь Васян-распиздяй может записать себя как угодно. Возраст — минус пять лет, зарплата — три бутылки, а email — «пошел_нахуй@». И что, блядь, мы с этим делать будем? А ничего! Пиздец и бардак.
Вот для этого и придумали ограничения (constraints). Это такие суровые бабайки от СУБД, которые стоят на страже порядка и целостности данных. Они смотрят на каждую вставленную или изменённую запись и говорят: «А ну-ка, пиздуй сюда, давай проверим, ты кто такой?».
Основные типы этих охранников:
| Ограничение | Что делает? | Пример на SQL (CREATE TABLE) |
|---|---|---|
PRIMARY KEY |
Это главный паспорт строки. Без него — ты бомж, нихуя не личность. Не может быть NULL и повторяться. |
id INT PRIMARY KEY |
FOREIGN KEY |
О, это уже связи, блядь! Ссылочная целостность. Не даёт тебе записать в поле user_id цифру, которой нет в таблице пользователей. Следит, чтобы ты не сослался в никуда, как дурак. |
FOREIGN KEY (user_id) REFERENCES Users(id) |
NOT NULL |
Самый простой охранник. «Поле не может быть пустым, мудила! Заполняй!». | name VARCHAR(100) NOT NULL |
UNIQUE |
«Уникальность, сука!». Все значения в столбце должны быть разными. Два одинаковых email? Иди нахуй, регистрируйся заново. | email VARCHAR(255) UNIQUE |
CHECK |
Вот это уже логика, ёпта! Проверяет значение по условию. Возраст больше 18? Зарплата не отрицательная? А то щас как впендюрю! | age INT CHECK (age >= 18) |
DEFAULT |
Ленивый, но добрый охранник. Если ты ничего не указал, он сам подставит стандартное значение. «Да похуй, пусть будет сегодняшняя дата». | created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP |
Вот тебе живой пример, как это всё вместе работает:
CREATE TABLE Employees (
emp_id INT PRIMARY KEY, -- Это твой служебный номер, уникальный и ебать он обязателен
name VARCHAR(100) NOT NULL, -- Без имени — ты анонимный пидор, не подходи
email VARCHAR(255) UNIQUE NOT NULL, -- Почта должна быть и одна на всех, чтоб не было клонов
department_id INT, -- А вот отдел может быть и NULL, если ты пока бездельник
salary DECIMAL(10,2) CHECK (salary > 0), -- Зарплата положительная, иначе это не зарплата, а долг, ебанашка
hire_date DATE DEFAULT (CURRENT_DATE), -- Дата приёма — сегодня, если не указал другую (лень, блядь, было?)
FOREIGN KEY (department_id) REFERENCES Departments(id) -- А это связь. Не даст тебе приписать себя к отделу-призраку.
);Итог, блядь: Ограничения — это офигенная штука. Они переносят всю эту ебучую логику проверок с твоего кривого кода в приложении прямо в ядро базы данных. Данные становятся надёжными, согласованными, и ты можешь спать спокойно, не боясь, что завтра в отчёте появится сотрудник с зарплатой в «пиздец денег» и датой рождения 32 июня. Чихать тебе в сраку, Васян!