Использование составного ключа в БД

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

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

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

Ну да хватит возмущений, перейду уже к практической части вопроса.

Часто бывает ситуация когда нужно связать значение из одной таблицы со значением из другой, при этом для одой записи (строки) одной таблицы может быть множество записей из другой и наоборот. Да, если бы связь была один к одному, то всё было бы просто но нет! Почти всегда нужны именно гибкие связи как одни к одному, один ко многим, многие ко многим. В этом случае требуется третья таблица, которая и будет по всякому связывать записи этих двух таблиц. Обычно в такой таблице всего 2 колонки (id уникальной строки из первой таблицы и id уникальной строки из второй таблицы), при этом, если не создавать ключей, то редактировать строки данной таблицы будет попросту невозможно т.к. у её столбцов не будет ограничения ключа просто потому, что на одну колонку данной таблицы нельзя поставить ограничение ключа т.к. значения в каждой из колонок могут повторятся. В этой ситуации можно создать дополнительный третий столбец id, который будет иметь ограничение первичного или просто уникального ключа и нумеровать уникальными идентификаторами каждую строку связи в этой таблице, но это расточительно в плане ресурсов и вообще не правильно с точки зрения проектирования. Суть в том, что в этой третьей связующей таблице не должно быть одинаковых строк, т.е. одинаковых связей ведь зачем нам отмечать связь которая уже есть. В этом случае на помощь приходит именно ограничение уникального составного ключа, который решит все проблемы. Не придётся создавать дополнительное третье поле id и так же решится проблема с одинаковыми строками, вставлять их будет нельзя. При таком подходе вся строка таблицы будет являться одним уникальным ключом, т.е. можно будет свободно редактировать строки данной таблицы.

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

Собственно к таблице ограничение составного уникального ключа с названием по умолчанию добавляется очень просто следующим образом:

ALTER TABLE bar ADD UNIQUE KEY (id_room, id_character);

или с указанием названия ограничения так:

ALTER TABLE bar ADD CONSTRAINT newUniqueConstraint
UNIQUE (id_room, id_character);

Где bar — название таблицы, newUniqueConstraint — название ограничения, id_room и id_character — столбцы таблицы образующие составное ограничение уникального ключа соответственно.

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

Поделиться!
Tags: , , ,

49.71MB | MySQL:52 | 0,278sec