Руководство по созданию эффективных запросов

Листинг 9.8 

Таблица аэропортов
CREATE TABLE airport
( airport_code char(3) NOT NULL,
airport_name text NOT NULL,
city text NOT NULL,
airport_tz text NOT NULL,
continent text,
iso_country text,
iso_region text,
intnl boolean NOT NULL,
update_ts timestamptz,
CONSTRAINT airport_pkey PRIMARY KEY (airport_code)
);
Точно так же самолеты идентифицируются трехсимвольными кодами, 
и мы используем их в качестве первичного ключа для таблицы 
aircraft
, см. 
лис тинг 9.9.
Листинг 9.9 

Таблица самолетов
CREATE TABLE aircraft
( model text,
range numeric NOT NULL,
class integer NOT NULL,
velocity numeric NOT NULL,
code text NOT NULL,
CONSTRAINT aircraft_pkey PRIMARY KEY (code)
)

---

Правильное и неправильное использование суррогатных ключей 

177
Для таблицы бронирования (показанной в лис тинге 9.10) используется 
суррогатный первичный ключ 
booking_id
, несмотря на то что имеется шес-
тизначный номер 
booking_ref
, который однозначно идентифицирует бро-
нирование и никогда не меняется. Этот номер тоже является суррогатным 
ключом, хотя он и не получен из последовательности базы данных. Мы могли 
бы использовать его в качестве первичного ключа. Таким образом, столбец 
booking_id
является избыточным, хотя он может пригодиться, если брониро-
вания будут поступать из разных приложений. Определения таблиц такого 
вида встречаются во многих промышленных системах.
Листинг 9.10 

Таблица бронирования
CREATE TABLE booking
( booking_id bigint NOT NULL,
booking_ref text NOT NULL,
booking_name text,
account_id integer,
email text NOT NULL,
phone text NOT NULL,
update_ts timestamptz,
price numeric(7,2),
CONSTRAINT booking_pkey PRIMARY KEY (booking_id),
CONSTRAINT booking_booking_ref_key UNIQUE (booking_ref),
CONSTRAINT booking_account_id_fk FOREIGN KEY (account_id)
REFERENCES account (account_id)
);
Таблица перелетов 
booking_leg
(лис тинг 9.11) связывает бронирования 
с рейсами. Следовательно, естественный ключ для этой таблицы будет состо-
ять из 
flight_id
и 
booking_id
, то есть из двух внешних ключей, ссылающихся 
на таблицы 
flight
и 
booking
. Эта пара столбцов была бы отличным первичным 
ключом. Решение создать дополнительный суррогатный ключ 
booking_leg_id
было вызвано желанием избежать ссылок на составной ключ из зависимой 
таблицы (на таблицу 
booking_leg
ссылается таблица 
boarding_pass
, которая 
является самой большой таблицей в базе данных).