mirror of
https://github.com/treffynnon/sqlstyle.guide.git
synced 2025-03-09 12:49:51 -05:00
Restrict text length to 80 symbols
This commit is contained in:
Den Patin
parent
9b99520651
commit
4264615046
1 changed files with 174 additions and 64 deletions
|
|
@ -4,13 +4,29 @@
|
|||
|
||||
## Предисловие
|
||||
|
||||
Вы можете использовать это руководство целиком, [сделать его форк][fork] или создать своё на его основе. Цель — определить, какой стиль вам подходит больше, и придерживаться его. Если вы хотите предложить изменение или исправить ошибку, [откройте Issue][issue] или [создайте Pull Request][pull] на GitHub'е.
|
||||
Вы можете использовать это руководство целиком, [сделать его форк][fork] или
|
||||
создать своё на его основе. Цель — определить, какой стиль вам подходит больше,
|
||||
и придерживаться его. Если вы хотите предложить изменение или исправить ошибку,
|
||||
[откройте Issue][issue] или [создайте Pull Request][pull] на GitHub'е.
|
||||
|
||||
Рекомендации, описанные в этом руководстве, во многом пересекаются с описанными в книге Джо Селко «[Стиль программирования Джо Селко на SQL][celko-ru]» (оригинал: [SQL Programming Style][celko]). Это, в частности, найдут полезным те, кто уже знаком с этой книгой. Тем не менее автор этого руководства в некоторых аспектах более категоричен, нежели Джо Селко, а в других, напротив, более гибок. И, конечно, нельзя не отметить, что это руководство значительно короче и лаконичнее [книги Селко][celko-ru] — здесь вы не встретите ни весёлых историй из жизни, наглядно объясняющих, как и почему лучше не делать, ни длинных повествований, мотивирующих на использование той или иной рекомендации.
|
||||
Рекомендации, описанные в этом руководстве, во многом пересекаются с описанными
|
||||
в книге Джо Селко «[Стиль программирования Джо Селко на SQL][celko-ru]»
|
||||
(оригинал: [SQL Programming Style][celko]). Это, в частности, найдут полезным
|
||||
те, кто уже знаком с этой книгой. Тем не менее автор этого руководства в
|
||||
некоторых аспектах более категоричен, нежели Джо Селко, а в других, напротив,
|
||||
более гибок. И, конечно, нельзя не отметить, что это руководство значительно
|
||||
короче и лаконичнее [книги Селко][celko-ru] — здесь вы не встретите ни весёлых
|
||||
историй из жизни, наглядно объясняющих, как и почему лучше не делать, ни длинных
|
||||
повествований, мотивирующих на использование той или иной рекомендации.
|
||||
|
||||
Руководство написано в [формате Markdown][dl-md], что позволяет легко включить его в проект или просто сослаться на него оттуда, что гораздо удобнее, нежели работать с большой бумажной книгой.
|
||||
Руководство написано в [формате Markdown][dl-md], что позволяет легко включить
|
||||
его в проект или просто сослаться на него оттуда, что гораздо удобнее, нежели
|
||||
работать с большой бумажной книгой.
|
||||
|
||||
«SQL: Руководство по стилю» (SQL style guide) за авторством Саймона Холиуэлла (Simon Holywell) находится под лицензией [Creative Commons «Атрибуция — На тех же условиях» 4.0 Всемирная][licence-ru]. Оригинал — [http://www.sqlstyle.guide][sqlstyleguide].
|
||||
«SQL: Руководство по стилю» (SQL style guide) за авторством Саймона Холиуэлла
|
||||
(Simon Holywell) находится под лицензией [Creative Commons «Атрибуция — На тех
|
||||
же условиях» 4.0 Всемирная][licence-ru]. Оригинал —
|
||||
[http://www.sqlstyle.guide][sqlstyleguide].
|
||||
|
||||
## Основные положения
|
||||
|
||||
|
|
@ -18,10 +34,15 @@
|
|||
|
||||
* **Идентификаторы и имена**. Осмысленные и в едином стиле.
|
||||
* **Пробелы и отступы**. Логично расставленные для лучшей читаемости кода.
|
||||
* **Дата и время**. Соответствующие стандарту [ISO 8601][iso-8601-ru]: `YYYY-MM-DD HH:MM:SS.SSSSS`.
|
||||
* **Функции SQL**. Стандартные вместо специфичных (определяемых поставщиком) с целью лучшей переносимости.
|
||||
* **Код**. Лаконичный и без излишеств, как например: ненужные кавычки или скобки или неуместное использование оператора `WHERE`.
|
||||
* **Комментарии**. Предпочтительно в [стиле C][c-style-comments-ru] — `/*` (начало) и `*/` (конец). Либо `--` перед комментарием, тогда окончанием будет новая строка.
|
||||
* **Дата и время**. Соответствующие стандарту [ISO 8601][iso-8601-ru]:
|
||||
`YYYY-MM-DD HH:MM:SS.SSSSS`.
|
||||
* **Функции SQL**. Стандартные вместо специфичных (определяемых поставщиком) с
|
||||
целью лучшей переносимости.
|
||||
* **Код**. Лаконичный и без излишеств, как например: ненужные кавычки или скобки
|
||||
или неуместное использование оператора `WHERE`.
|
||||
* **Комментарии**. Предпочтительно в [стиле C][c-style-comments-ru] — `/*`
|
||||
(начало) и `*/` (конец). Либо `--` перед комментарием, тогда окончанием будет
|
||||
новая строка.
|
||||
|
||||
```sql
|
||||
SELECT file_hash -- stored ssdeep hash
|
||||
|
|
@ -39,22 +60,32 @@ UPDATE file_system
|
|||
### Плохой стиль
|
||||
|
||||
* **CamelCase**. Неудобочитаем.
|
||||
* **Префиксы и [венгерская нотация][hungarian-notation-ru]**. Префиксы наподобие `sp_` или `tbl_` избыточны.
|
||||
* **Множественное число**. Лучше использовать более естественно звучащие собирательные понятия. Например, `staff` вместо `employees` или `people` вместо `individuals`.
|
||||
* **Идентификаторы в кавычках**. Если они обязательно нужны, тогда используйте двойные кавычки, определённые в стандарте [SQL-92][sql-92-ru] с целью лучшей переносимости в дальнейшем.
|
||||
* **Принципы объектно-ориентированного проектирования**. Не нужно применять к SQL или структуре базы данных.
|
||||
* **Префиксы и [венгерская нотация][hungarian-notation-ru]**. Префиксы наподобие
|
||||
`sp_` или `tbl_` избыточны.
|
||||
* **Множественное число**. Лучше использовать более естественно звучащие
|
||||
собирательные понятия. Например, `staff` вместо `employees` или `people`
|
||||
вместо `individuals`.
|
||||
* **Идентификаторы в кавычках**. Если они обязательно нужны, тогда используйте
|
||||
двойные кавычки, определённые в стандарте [SQL-92][sql-92-ru] с целью лучшей
|
||||
переносимости в дальнейшем.
|
||||
* **Принципы объектно-ориентированного проектирования**. Не нужно применять к
|
||||
SQL или структуре базы данных.
|
||||
|
||||
## Соглашения о наименовании
|
||||
|
||||
### Общее
|
||||
|
||||
* **Убедитесь** в том, что имя уникально и его нет в [списке зарезервированных ключевых слов][reserved-keywords].
|
||||
* **Ограничивайте** длину имени 30 байтами (это 30 символов, если не используется многобайтовый набор символов).
|
||||
* **Убедитесь** в том, что имя уникально и его нет в
|
||||
[списке зарезервированных ключевых слов][reserved-keywords].
|
||||
* **Ограничивайте** длину имени 30 байтами (это 30 символов, если не
|
||||
используется многобайтовый набор символов).
|
||||
* **Начинайте** имена с буквы и **не заканчивайте** их символом подчёркивания.
|
||||
* **Используйте** в именах только буквы, цифры и символ подчёркивания.
|
||||
* **Избегайте** нескольких подряд идущих символов подчёркивания.
|
||||
* **Используйте** символ подчёркивания там, где вы бы поставили пробел в реальной жизни (например, `first name` станет `first_name`).
|
||||
* **Избегайте** сокращений. Если их всё же нужно использовать, убедитесь в том, что они общепонятны.
|
||||
* **Используйте** символ подчёркивания там, где вы бы поставили пробел в
|
||||
реальной жизни (например, `first name` станет `first_name`).
|
||||
* **Избегайте** сокращений. Если их всё же нужно использовать, убедитесь в том,
|
||||
что они общепонятны.
|
||||
|
||||
```sql
|
||||
SELECT first_name
|
||||
|
|
@ -63,25 +94,36 @@ SELECT first_name
|
|||
|
||||
### Таблицы
|
||||
|
||||
* **Используйте** собирательные имена или, что менее предпочтительно, форму множественного числа. Например, `staff` и `employees` (в порядке убывания предпочтения).
|
||||
* **Не используйте** описательные префиксы вида `tbl_` и венгерскую нотацию в целом.
|
||||
* **Не допускайте** совпадений названия таблицы с названием любого из её столбцов.
|
||||
* По возможности **избегайте** объединения названий двух таблиц для построения таблицы отношений. Например, вместо названия `cars_mechanics` лучше подойдёт `services`.
|
||||
* **Используйте** собирательные имена или, что менее предпочтительно, форму
|
||||
множественного числа. Например, `staff` и `employees` (в порядке убывания
|
||||
предпочтения).
|
||||
* **Не используйте** описательные префиксы вида `tbl_` и венгерскую нотацию в
|
||||
целом.
|
||||
* **Не допускайте** совпадений названия таблицы с названием любого из её
|
||||
столбцов.
|
||||
* По возможности **избегайте** объединения названий двух таблиц для построения
|
||||
таблицы отношений. Например, вместо названия `cars_mechanics` лучше подойдёт
|
||||
`services`.
|
||||
|
||||
### Столбцы
|
||||
|
||||
* Названия всегда **давайте** в единственном числе.
|
||||
* По возможности **не используйте** `id` в качестве первичного идентификатора таблицы.
|
||||
* По возможности **не используйте** `id` в качестве первичного идентификатора
|
||||
таблицы.
|
||||
* **Не создавайте** в таблице столбцов с таким же названием, как у неё самой.
|
||||
* Названия **всегда пишите** со строчной буквы. Могут быть исключения, например использование имени собственного.
|
||||
* Названия **всегда пишите** со строчной буквы. Могут быть исключения, например
|
||||
использование имени собственного.
|
||||
|
||||
### Псевдонимы/корреляции
|
||||
|
||||
* **Должны** так или иначе быть связаны с объектами или выражениями, псевдонимом которых они являются.
|
||||
* Имя корреляции **обычно составляется** из первых букв каждого слова в имени объекта.
|
||||
* **Должны** так или иначе быть связаны с объектами или выражениями, псевдонимом
|
||||
которых они являются.
|
||||
* Имя корреляции **обычно составляется** из первых букв каждого слова в имени
|
||||
объекта.
|
||||
* **Добавьте** цифру к имени, если такое уже существует.
|
||||
* Всегда **используйте** ключевое слово `AS` для лучшей читаемости.
|
||||
* Для вычислимых данных (`SUM()` или `AVG()`) **используйте** такие имена, которые вы бы дали, будь они столбцами в таблице.
|
||||
* Для вычислимых данных (`SUM()` или `AVG()`) **используйте** такие имена,
|
||||
которые вы бы дали, будь они столбцами в таблице.
|
||||
|
||||
```sql
|
||||
SELECT first_name AS fn
|
||||
|
|
@ -97,11 +139,13 @@ SELECT SUM(s.monitor_tally) AS monitor_total
|
|||
### Хранимые процедуры
|
||||
|
||||
* Имя **должно** содержать глагол.
|
||||
* **Не используйте** описательные префиксы вида `sp_` и венгерскую нотацию в целом.
|
||||
* **Не используйте** описательные префиксы вида `sp_` и венгерскую нотацию в
|
||||
целом.
|
||||
|
||||
### Универсальные суффиксы
|
||||
|
||||
Приведённые ниже суффиксы универсальны, что гарантирует простоту понимания значения столбцов из кода SQL.
|
||||
Приведённые ниже суффиксы универсальны, что гарантирует простоту понимания
|
||||
значения столбцов из кода SQL.
|
||||
|
||||
* `_id` — уникальный идентификатор, например первичный ключ.
|
||||
* `_status` — флаг или любой статус, например `publication_status`.
|
||||
|
|
@ -118,11 +162,15 @@ SELECT SUM(s.monitor_tally) AS monitor_total
|
|||
|
||||
### Зарезервированные слова
|
||||
|
||||
[Зареервированные ключевые слова][reserved-keywords] всегда пишите прописными буквами, например `SELECT`, `WHERE`.
|
||||
[Зареервированные ключевые слова][reserved-keywords] всегда пишите прописными
|
||||
буквами, например `SELECT`, `WHERE`.
|
||||
|
||||
Не испольуйте сокращённый вариант ключевого слова, если имеется полный. Например, используйте `ABSOLUTE` вместо `ABS`.
|
||||
Не испольуйте сокращённый вариант ключевого слова, если имеется полный.
|
||||
Например, используйте `ABSOLUTE` вместо `ABS`.
|
||||
|
||||
Не испольуйте специфичные для какого-либо поставщика СУБД ключевые слова, если в ANSI SQL есть ключевые слова, выполняющие такие же функции. Это сделает ваш код более переносимым.
|
||||
Не испольуйте специфичные для какого-либо поставщика СУБД ключевые слова, если в
|
||||
ANSI SQL есть ключевые слова, выполняющие такие же функции. Это сделает ваш код
|
||||
более переносимым.
|
||||
|
||||
```sql
|
||||
SELECT model_num
|
||||
|
|
@ -132,11 +180,15 @@ SELECT model_num
|
|||
|
||||
### Пробельные символы
|
||||
|
||||
Для лучшей удобочитаемости кода важно правильно использовать пробельные символы. Не нужно нагромождать код или удалять пробелы, присущие естественному языку.
|
||||
Для лучшей удобочитаемости кода важно правильно использовать пробельные символы.
|
||||
Не нужно нагромождать код или удалять пробелы, присущие естественному языку.
|
||||
|
||||
#### Пробелы
|
||||
|
||||
Можно и нужно использовать пробелы для выравнивания основных ключевых слов по их правому краю. В типографике получающиеся таким образом «[коридоры][rivers-ru]» стараются избегать, в то же время в нашем случае они, напротив, помогают лучше вычленять важные ключевые слова.
|
||||
Можно и нужно использовать пробелы для выравнивания основных ключевых слов по их
|
||||
правому краю. В типографике получающиеся таким образом «[коридоры][rivers-ru]»
|
||||
стараются избегать, в то же время в нашем случае они, напротив, помогают лучше
|
||||
вычленять важные ключевые слова.
|
||||
|
||||
```sql
|
||||
(SELECT f.species_name,
|
||||
|
|
@ -158,13 +210,16 @@ SELECT model_num
|
|||
GROUP BY b.species_name, b.observation_date)
|
||||
```
|
||||
|
||||
Обратите внимание, что ключевые слова `SELECT`, `FROM` и т.д. выровнены по правому краю, при этом названия столбцов и различные условия — по левому.
|
||||
Обратите внимание, что ключевые слова `SELECT`, `FROM` и т.д. выровнены по
|
||||
правому краю, при этом названия столбцов и различные условия — по левому.
|
||||
|
||||
Помимо этого, старайтесь расставлять пробелы:
|
||||
|
||||
* **до** и **после** знака равно (`=`)
|
||||
* **после** запятых (`,`)
|
||||
* **до** открывающего и **после** закрывающего апострофов (`'`), если последний не внутри скобок, или без последующих запятой или точки с запятой, или не в конце строки
|
||||
* **до** открывающего и **после** закрывающего апострофов (`'`), если последний
|
||||
не внутри скобок, или без последующих запятой или точки с запятой, или не в
|
||||
конце строки
|
||||
|
||||
```sql
|
||||
SELECT a.title, a.release_date, a.recording_date
|
||||
|
|
@ -182,7 +237,9 @@ SELECT a.title, a.release_date, a.recording_date
|
|||
* **после** каждого основного ключевого слова
|
||||
* **после** запятой (при выделении логических групп столбцов)
|
||||
|
||||
Следуя принципу, что ключевые слова выравниваются по правому краю, а всё остальное — по левому, мы добиваемся достаточно удобного расположения частей кода, вследствие чего улучшается зрительная навигация по нему.
|
||||
Следуя принципу, что ключевые слова выравниваются по правому краю, а всё
|
||||
остальное — по левому, мы добиваемся достаточно удобного расположения частей
|
||||
кода, вследствие чего улучшается зрительная навигация по нему.
|
||||
|
||||
```sql
|
||||
INSERT INTO albums (title, release_date, recording_date)
|
||||
|
|
@ -206,11 +263,13 @@ SELECT a.title,
|
|||
|
||||
### Отступы
|
||||
|
||||
Для того, чтобы SQL был удобочитаем, важно также следовать стандартам расстановки отступов.
|
||||
Для того, чтобы SQL был удобочитаем, важно также следовать стандартам
|
||||
расстановки отступов.
|
||||
|
||||
#### `JOIN`
|
||||
|
||||
Объединения (`JOIN`) должны располагаться по правую часть «коридора». При необходимости между ними можно добавить пустую строку.
|
||||
Объединения (`JOIN`) должны располагаться по правую часть «коридора». При
|
||||
необходимости между ними можно добавить пустую строку.
|
||||
|
||||
```sql
|
||||
SELECT r.last_name
|
||||
|
|
@ -226,7 +285,10 @@ SELECT r.last_name
|
|||
|
||||
#### Подзапросы
|
||||
|
||||
Подзапросы тоже должны быть выровнены по правому краю «коридора», а внутри них самих применяются те же правила форматирования, что и в любом другом запросе. Если используются вложенные подзапросы, может иметь смысл поставить закрывающую скобку на новой строке ровно под парной ей открывающей скобкой.
|
||||
Подзапросы тоже должны быть выровнены по правому краю «коридора», а внутри них
|
||||
самих применяются те же правила форматирования, что и в любом другом запросе.
|
||||
Если используются вложенные подзапросы, может иметь смысл поставить закрывающую
|
||||
скобку на новой строке ровно под парной ей открывающей скобкой.
|
||||
|
||||
```sql
|
||||
SELECT r.last_name,
|
||||
|
|
@ -246,7 +308,9 @@ SELECT r.last_name,
|
|||
|
||||
* **Используйте** `BETWEEN`, где возможно, вместо нагромождения условий `AND`.
|
||||
* Таким же образом старайтесь **использовать** `IN()` вместо `OR`.
|
||||
* **Используйте** `CASE`, если значение должно быть интерпретировано до окончания выполнения запроса. С помощью `CASE` можно также формировать сложные логические структуры.
|
||||
* **Используйте** `CASE`, если значение должно быть интерпретировано до
|
||||
окончания выполнения запроса. С помощью `CASE` можно также формировать сложные
|
||||
логические структуры.
|
||||
* По возможности **избегайте** использования `UNION` и временных таблиц.
|
||||
|
||||
```sql
|
||||
|
|
@ -262,58 +326,93 @@ SELECT CASE postcode
|
|||
|
||||
## Синтаксис `CREATE`
|
||||
|
||||
При разработке схемы данных важно создавать человекочитаемый код. Убедитесь в том, что объявления столбцов логически структурированы и сгруппированы.
|
||||
При разработке схемы данных важно создавать человекочитаемый код. Убедитесь в
|
||||
том, что объявления столбцов логически структурированы и сгруппированы.
|
||||
|
||||
Внутри объявления `CREATE` делайте отступ, равный 4 пробелам.
|
||||
|
||||
### Типы данных
|
||||
|
||||
* По возможности **не используйте** специфичные для той или иной СУБД типы данных. Это может негативно сказаться на переносимости, а также этих типов может не оказаться в старых версиях этих же СУБД.
|
||||
* Для работы с плавающей точкой **используйте** только `REAL` или `FLOAT`, но где нет необходимости в подобных вычислениях, всегда **используйте** `NUMERIC` и `DECIMAL`. Ошибки округления в операциях с плавающей точкой могут оказаться очень некстати.
|
||||
* По возможности **не используйте** специфичные для той или иной СУБД типы
|
||||
данных. Это может негативно сказаться на переносимости, а также этих типов может
|
||||
не оказаться в старых версиях этих же СУБД.
|
||||
* Для работы с плавающей точкой **используйте** только `REAL` или `FLOAT`, но
|
||||
где нет необходимости в подобных вычислениях, всегда **используйте** `NUMERIC`
|
||||
и `DECIMAL`. Ошибки округления в операциях с плавающей точкой могут оказаться
|
||||
очень некстати.
|
||||
|
||||
### Значения по умолчанию
|
||||
|
||||
* Значение по умолчанию всегда должно **совпадать** по типу со столбцом. Если, скажем, столбец объявлен как `DECIMAL`, не нужно в качестве умолчания указывать значение типа `INTEGER`.
|
||||
* Значения по умолчанию должны располагаться **после** объявления типа столбца и **перед** пометкой `NOT NULL`.
|
||||
* Значение по умолчанию всегда должно **совпадать** по типу со столбцом. Если,
|
||||
скажем, столбец объявлен как `DECIMAL`, не нужно в качестве умолчания
|
||||
указывать значение типа `INTEGER`.
|
||||
* Значения по умолчанию должны располагаться **после** объявления типа столбца и
|
||||
**перед** пометкой `NOT NULL`.
|
||||
|
||||
### Ограничения и ключи
|
||||
|
||||
Ограничения и их подмножество, ключи, — важная часть любой структуры базы данных, поэтому важно следовать стандартам их объявления, чтобы избежать трудностей в последующей поддержке написанного.
|
||||
Ограничения и их подмножество, ключи, — важная часть любой структуры базы
|
||||
данных, поэтому важно следовать стандартам их объявления, чтобы избежать
|
||||
трудностей в последующей поддержке написанного.
|
||||
|
||||
#### Ключи
|
||||
|
||||
Выбор столбцов, которые будут играть роль ключей, должен быть обоснован и предельно выверен, поскольку от них напрямую зависит производительность и целостность данных.
|
||||
Выбор столбцов, которые будут играть роль ключей, должен быть обоснован и
|
||||
предельно выверен, поскольку от них напрямую зависит производительность и
|
||||
целостность данных.
|
||||
|
||||
1. Ключ должен быть в какой-то степени уникальным.
|
||||
2. Должна быть согласованность по типу данных для значения во всей схеме, а также чем ниже вероятность того, что это изменится в будущем, тем лучше.
|
||||
2. Должна быть согласованность по типу данных для значения во всей схеме, а
|
||||
также чем ниже вероятность того, что это изменится в будущем, тем лучше.
|
||||
3. Можно ли проверить значение на соответствие стандарту (например, ISO)?
|
||||
4. Ключ должен быть как можно проще, чтобы можно было без трудностей использовать составные ключи.
|
||||
4. Ключ должен быть как можно проще, чтобы можно было без трудностей
|
||||
использовать составные ключи.
|
||||
|
||||
Это своего рода конвенции, которые нужно сформулировать при проектировании базы данных. Если требования впоследствии будут разрастаться, можно и нужно вносить изменения в структуру базы, чтобы поддерживать её в актуальном состоянии.
|
||||
Это своего рода конвенции, которые нужно сформулировать при проектировании базы
|
||||
данных. Если требования впоследствии будут разрастаться, можно и нужно вносить
|
||||
изменения в структуру базы, чтобы поддерживать её в актуальном состоянии.
|
||||
|
||||
#### Ограничения
|
||||
|
||||
Как только решено, какие ключи должны использоваться, нужно определить их в базе с помощью ограничений наряду с валидацией значений полей.
|
||||
Как только решено, какие ключи должны использоваться, нужно определить их в базе
|
||||
с помощью ограничений наряду с валидацией значений полей.
|
||||
|
||||
##### Общее
|
||||
|
||||
* У каждой таблицы **должен быть** хотя бы один ключ.
|
||||
* Ограничениям нужно **присваивать** вразумительные имена. Для `UNIQUE`, `PRIMARY KEY` и `FOREIGN KEY` подобные имена создаются автоматически, поэтому нужно позаботиться об остальных ограничениях.
|
||||
* Ограничениям нужно **присваивать** вразумительные имена. Для `UNIQUE`,
|
||||
`PRIMARY KEY` и `FOREIGN KEY` подобные имена создаются автоматически, поэтому
|
||||
нужно позаботиться об остальных ограничениях.
|
||||
|
||||
##### Расположение и порядок
|
||||
|
||||
* Первичный ключ должен быть **объявлен** в самом начале, сразу после оператора `CREATE TABLE`.
|
||||
* Ограничения должны быть **объявлены** строго ниже столбца, с которым они связаны. Расставьте отступы так, чтобы объявление ограничения начиналось после названия столбца.
|
||||
* В случае ограничений, затрагивающих несколько столбцов, старайтесь **объявлять** их как можно ближе к описанию последнего из них. В крайнем случае объявляйте ограничение в конце тела `CREATE TABLE`.
|
||||
* Первичный ключ должен быть **объявлен** в самом начале, сразу после оператора
|
||||
`CREATE TABLE`.
|
||||
* Ограничения должны быть **объявлены** строго ниже столбца, с которым они
|
||||
связаны. Расставьте отступы так, чтобы объявление ограничения начиналось после
|
||||
названия столбца.
|
||||
* В случае ограничений, затрагивающих несколько столбцов, старайтесь
|
||||
**объявлять** их как можно ближе к описанию последнего из них. В крайнем
|
||||
случае объявляйте ограничение в конце тела `CREATE TABLE`.
|
||||
* Ограничения целостности уровня таблицы должны **располагаться** в конце.
|
||||
* **Используйте** алфавитный порядок там, где `ON DELETE` предшествует `ON UPDATE`.
|
||||
* Внутри запроса можно **выравнивать** каждый уровень по-своему. Например, можно добавить отступы после названия столбцов, чтобы типы данных начинались с одной позиции, а затем ещё добавить отступов в нужном количестве, чтобы все объявления `NOT NULL` тоже были выровнены по левому краю. Подобное форматирование позволит быстрее ориентироваться в коде.
|
||||
* **Используйте** алфавитный порядок там, где `ON DELETE` предшествует
|
||||
`ON UPDATE`.
|
||||
* Внутри запроса можно **выравнивать** каждый уровень по-своему. Например, можно
|
||||
добавить отступы после названия столбцов, чтобы типы данных начинались с одной
|
||||
позиции, а затем ещё добавить отступов в нужном количестве, чтобы все
|
||||
объявления `NOT NULL` тоже были выровнены по левому краю. Подобное
|
||||
форматирование позволит быстрее ориентироваться в коде.
|
||||
|
||||
##### Валидация
|
||||
|
||||
* **Используйте** `LIKE` и `SIMILAR TO` для обеспечения целостности строк с известным форматом.
|
||||
* Если диапазон числовых значений для столбца известен, **используйте** `CHECK()` для предотвращения внесения в базу некорректных данных или скрытого отсечения части значения слишком больших данных. Обычно проверка делается на то, что значение больше нуля.
|
||||
* `CHECK()` должен быть **объявлен** как отдельное ограничение для упрощения последующей отладки.
|
||||
* **Используйте** `LIKE` и `SIMILAR TO` для обеспечения целостности строк с
|
||||
известным форматом.
|
||||
* Если диапазон числовых значений для столбца известен, **используйте**
|
||||
`CHECK()` для предотвращения внесения в базу некорректных данных или скрытого
|
||||
отсечения части значения слишком больших данных. Обычно проверка делается на
|
||||
то, что значение больше нуля.
|
||||
* `CHECK()` должен быть **объявлен** как отдельное ограничение для упрощения
|
||||
последующей отладки.
|
||||
|
||||
##### Пример
|
||||
|
||||
|
|
@ -330,10 +429,20 @@ CREATE TABLE staff (
|
|||
|
||||
### Чего следует избегать
|
||||
|
||||
* **Не применяйте** объектно-ориентированные принципы, поскольку они далеко не всегда оптимально ложатся на реляционную модель баз данных.
|
||||
* **Не разносите** по разным столбцам значения и единицы измерения. Нужно создавать столбцы так, чтобы единицы измерения были чем-то самим собой разумеющимся. Для проверки корректности вставляемых в столбец данных используйте `CHECK()`.
|
||||
* **Избегайте** паттерна [EAV (Entity Attribute Value)][eav]. Вместо него используйте специальные продукты, предназначенные для работы с неструктурированными данными.
|
||||
* **Не разбивайте** данные, логически принадлежащие одной таблице, по разным таблицам на основании условностей, например архивации по времени или географическим атрибутам. Впоследствии для работы с несколькими подобными таблицам придётся часто использовать `UNION` вместо простых запросов к одной таблице.
|
||||
* **Не применяйте** объектно-ориентированные принципы, поскольку они далеко не
|
||||
всегда оптимально ложатся на реляционную модель баз данных.
|
||||
* **Не разносите** по разным столбцам значения и единицы измерения. Нужно
|
||||
создавать столбцы так, чтобы единицы измерения были чем-то самим собой
|
||||
разумеющимся. Для проверки корректности вставляемых в столбец данных
|
||||
используйте `CHECK()`.
|
||||
* **Избегайте** паттерна [EAV (Entity Attribute Value)][eav]. Вместо него
|
||||
используйте специальные продукты, предназначенные для работы с
|
||||
неструктурированными данными.
|
||||
* **Не разбивайте** данные, логически принадлежащие одной таблице, по разным
|
||||
таблицам на основании условностей, например архивации по времени или
|
||||
географическим атрибутам. Впоследствии для работы с несколькими подобными
|
||||
таблицам придётся часто использовать `UNION` вместо простых запросов к одной
|
||||
таблице.
|
||||
|
||||
## Приложение
|
||||
|
||||
|
|
@ -341,7 +450,8 @@ CREATE TABLE staff (
|
|||
|
||||
### Список зарезервированных ключевых слов
|
||||
|
||||
Список зарезервированных ключевых слов ANSI SQL (92, 99 and 2003), MySQL версий с 3 по 5.x, PostgreSQL 8.1, MS SQL Server 2000, MS ODBC и Oracle 10.2.
|
||||
Список зарезервированных ключевых слов ANSI SQL (92, 99 and 2003), MySQL версий
|
||||
с 3 по 5.x, PostgreSQL 8.1, MS SQL Server 2000, MS ODBC и Oracle 10.2.
|
||||
|
||||
```sql
|
||||
A
|
||||
|
|
|
|||
Loading…
Reference in a new issue