Читаем Понимание SQL полностью

Обратите внимание что оба поля в ограничении таблицы UNIQUE все еще используют ограничение столбца - NOT NULL . Если бы мы использовали ограничение столбца UNIQUE для поля cnum, такое ограничение таблицы было бы необязательным. Если значения поля cnum различно для каждой строки, то не может быть двух строк с идентичной комбинацией значений полей cnum и snum. То же самое получится если мы обьявим поле snum уникальным, хотя это и не будет соответствовать нашему примеру, так как продавец будет назначен многочисленым заказчикам. Следовательно, ограничение таблицы - UNIQUE, наиболее полезно когда вы не хотите заставлять индивидуальные поля быть уникальными.

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

CREATE TABLE Salestotal

( cnum integer NOT NULL,

odate date NULL,

totamt decimal,

UNIQUE (snum, odate));

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

INSERT INTO Salestotal

SELECT snum, odate, SUM (amt)

FROM Orders

GROUP BY snum, odate;

ОГРАНИЧЕНИЕ ПЕРВИЧНЫХ КЛЮЧЕЙ

До этого мы воспринимали первичные ключи исключительно как логические понятия. Хоть мы и знаем что такое первичный ключ, и как он должен использоваться в любой таблице, мы не ведаем "знает" ли об этом SQL.

Поэтому мы использовали ограничение UNIQUE или уникальные индексы в первичных ключах чтобы предписывать им уникальность. В более ранних версиях языка SQL, это было необходимо, и могло выполняться этим способом. Однако теперь, SQL поддерживает первичные ключи непосредственно с ограничением Первичный Ключ (PRIMARE KEY). Это ограничение может быть доступным или недоступным вашей системе.

PRIMARY KEY может ограничивать таблицы или их столбцы. Это ограничение работает так же как и ограничение UNIQUE, за исключением когда только один первичный ключ (для любого числа столбцов ) может быть определен для данной таблицы. Имеется также различие между первичными ключами и уникальностью столбцов в способе их использоваться с внешними ключами, о которых будет рассказано в Главе 19. Синтаксис и определение их уникальности те же что и для ограничения UNIQUE.

Первичные ключи не могут позволять значений NULL. Это означает что, подобно полям в ограничении UNIQUE, любое поле используемое в ограничении PRIMARY KEY должно уже быть обьявлено NOT NULL. Имеется улучшеный вариант создания нашей таблицы Продавцов :

CREATE TABLE Salestotal

( snum integer NOT NULL PRIMARY KEY,

sname char(10) NOT NULL UNIQUE,

city char(10),

comm decimal);

Как вы видете, уникальность (UNIQUE) полей может быть обьявлена для той же самой таблицы. Лучше всего помещать ограничение PRIMARY KEY в поле(или в поля) которое будет образовывать ваш уникальный идентификатор строки, и сохранить ограничение UNIQUE для полей которые должны быть уникальными логически (такие как номера телефона или поле sname ), а не для идентификации строк.

ПЕРВИЧНЫЕ КЛЮЧИ БОЛЕЕ ЧЕМ ОДНОГО ПОЛЯ

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

Мы можем применить ограничение таблицы PRIMARY KEY для пар:

CREATE TABLE Namefield

( firstname char (10) NOT NULL,

lastname char (10) NOT NULL

city char (10),

PRIMARY KEY (firstname, lastname ));

Одна проблема в этом подходе та, что мы можем вынудить появление уникальности - например, введя Mary Smith и M. Smith. Это может ввести в заблуждение, потому что ваши служащие могут не знать кто из них кто.

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

ПРОВЕРКА ЗНАЧЕНИЙ ПОЛЕЙ
Перейти на страницу:

Похожие книги

97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT