Размещайте объявление primary KEY в начале оператора create table

Обоснование
Поставьте объявление первичного ключа в начале описания таблицы, и вы сообщите читателю важную информацию о природе таблицы и о том, как искать в ней информацию. Например, увидев в таблице “Персонал” первый столбец “ssn”, я сразу пойму, что работники идентифицируются по номеру социального страхования (social security number, SSN).

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

Располагайте столбцы в логической последовательности и объединяйте их в логические группы

Обоснование
Считается, что в реляционной модели физический порядок столбцов в таблице роли не играет. Идентификатором столбца является его имя, а не положение. Тем не менее, в ряде случаев SQL все-таки обращается к физическому расположению столбцов. В частности, в командах SELECT * и INSERT INTO по умолчанию используется тот порядок столбцов, в котором они были объявлены. Правило расположения столбцов очевидно: логическая последовательность лучше беспорядка. Скажем, столбцы для адреса логично расположить в таком порядке: имя, улица, город, государство, почтовый индекс.

Исключения
Может оказаться, что ваш SQL-продукт не допускает перестановки столбцов, добавленных после окончания разработки схемы. Проверьте, так ли это на самом деле.
В некоторых случаях бывает удобно воспользоваться особенностями физического расположения столбцов в конкретной реализации SQL. Например, в DB2 для OS/2 изменения в строках постоянной длины записываются от первого измененного байта до последнего измененного байта. В строках переменной длины изменения записываются от первого измененного байта до конца строки — если длина строки действительно изменилась. Если длина строки осталась той же самой, изменения опять же записываются от первого измененного байта до последнего измененного байта. Чтобы оптимизировать работу с базой данных, администратор может:
— поместить первыми нечасто обновляемые столбцы постоянной длины;
— затем поместить нечасто обновляемые столбцы переменной длины;
— последними поместить часто обновляемые столбцы;
— поставить рядом столбцы, которые, как правило, обновляются одновременно.
Выполнив эти рекомендации, вы до минимума сократите объем данных, записываемых в журнал изменений. Поскольку ведение журнала может очень серьезно сказываться на производительности, такая экономия будет весьма полезной. Для удобства разработчиков вы всегда вольны создать представление, в котором столбцы будут располагаться в более логически обоснованном порядке.

Выделяйте отступами ссылочные ограничения и действия

Обоснование
Идея состоит в том, чтобы при чтении выражения CREATE TABLE все объявление столбца визуально представляло собой единый блок. В частности, размещайте конструкции ON DELETE и ON UPDATE в отдельных строках. Стандарт не требует ставить их вместе или в каком-либо определенном порядке. Чтобы не мучаться с выбором, возьмите в качестве основы алфавит и ставьте ON DELETE перед ON UPDATE, если нужны обе конструкции.

Исключения
Нет.

Давайте имена ограничениям

Обоснование
Имя ограничения отображается в сообщении об ошибке, когда это ограничение нарушено. С помощью имен ограничений вы сможете создавать понятные сообщения, что существенно облегчает диагностику ошибок.
Синтаксис прост: “CONSTRAINT <имя>”. В качестве имени нужно использовать понятное описание ограничения, например:

CREATE TABLE Prizes (... award_points INTEGER DEFAULT 0 NOT NULL

CONSTRAINT award_point_range

CHECK (award_points BETWEEN 0 AND 100),

...);

Если вы не присвоите ограничению имя, SQL сгенерирует его самостоятельно. Оно будет длинным, нечитаемым и лишенным какой бы то ни было информации о сути проблемы.

Исключения
Имена можно не присваивать ограничениям PRIMARY KEY, UNIQUE и FOREIGN KEY, поскольку при их нарушении большинство SQL-продуктов выдает понятные сообщения об ошибке. Исключение составляет Oracle.
Без имен ограничений можно обойтись на этапе разработки. Помните, однако, что имена ограничений являются глобальными, а не локальными. В противном случае возможны были бы проблемы с выражением CREATE ASSERTION.