From 4264615046e87658fe5b64d58a5e2304187825fd Mon Sep 17 00:00:00 2001 From: Den Patin Date: Sun, 30 Apr 2017 11:50:10 +0300 Subject: [PATCH] Restrict text length to 80 symbols --- _includes/sqlstyle.guide.ru.md | 238 ++++++++++++++++++++++++--------- 1 file changed, 174 insertions(+), 64 deletions(-) diff --git a/_includes/sqlstyle.guide.ru.md b/_includes/sqlstyle.guide.ru.md index 368a9a7..928d3c7 100644 --- a/_includes/sqlstyle.guide.ru.md +++ b/_includes/sqlstyle.guide.ru.md @@ -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