Sql стандарт: Стандарты языка реляционных баз данных SQL: краткий обзор | Системы управления базами данных

Стандарты проектирования баз данных / Блог компании Mail.ru Group / Хабр

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

Эта статья не про нормализацию БД. Если хотите этому научиться, то здесь я вкратце рассказал основы.

Если у вас есть рабочая БД, то нужно ответить себе на вопрос: «какие стандарты можно применить для облегчения использования этой базы данных?». Если эти стандарты применялись широко, то вам будет легко пользоваться БД, потому что не придётся изучать и запоминать новые наборы стандартов каждый раз, начиная работу с новой БД.

Я постоянно сталкиваюсь с базами, в которых таблицы именованы в стиле CustomerOrders или customer_orders. Какой лучше использовать? Возможно, вы хотите применять уже устоявшийся стандарт, но если вы создаёте новую базу, то для повышения доступности рекомендую использовать_подчёркивания. Фраза «under value» имеет другое значение по сравнению с «undervalue», но с подчёркиванием первая будет всегда under_value, а вторая — undervalue. А при использовании CamelCase мы получим Undervalue и UnderValue, которые идентичны с точки зрения не чувствительного к регистру SQL. Более того, если у вас есть проблемы со зрением и вы постоянно экспериментируете с гарнитурами и кеглем, чтобы выделять слова, то подчёркивание читается гораздо легче.

Наконец, CamelCase труден в прочтении для тех, для кого английский не является родным.

Подводя итог, это не строгая рекомендация, а личное предпочтение.

Эксперты по теории баз данных давно спорят о том, должны ли таблицы быть в единственном числе (customer) или множественном (customers). Позвольте мне разрубить этот гордиев узел без углубления в теорию, просто с помощью прагматизма: имена таблиц во множественном числе с меньшей вероятностью конфликтуют с зарезервированными ключевыми словами.

У вас есть пользователи — users? В SQL есть ключевое слово user. Вам нужна таблица с ограничениями — constraints? constraint — это зарезервированное слово. Слово audit

зарезервировано, но вам нужна таблица audit? Просто используйте множественную форму существительных, и тогда большинство зарезервированных слов не доставят вам хлопот в SQL. Даже PostgreSQL, в котором есть прекрасный SQL-парсер, запнулся на таблице user.

Просто используйте множественное число, и вероятность конфликта будет гораздо ниже.

Я сам грешил этим годами. Однажды работал с клиентом в Париже, и администратор БД на меня пожаловался, когда я дал колонке с идентификаторами название id. Я думал, что он просто педант. Ведь, название колонки customers.id является однозначным, а customers.customer_id — это повтор информации.

А позднее мне пришлось отлаживать вот это:

SELECT thread.*
  FROM email thread
  JOIN email selected      ON selected.id = thread.id
  JOIN character recipient ON recipient.id = thread.recipient_id
  JOIN station_area sa     ON sa.id = recipient.id
  JOIN station st          ON st.id = sa.id
  JOIN star origin         ON origin.id = thread.id
  JOIN star destination    ON destination.id = st.id
LEFT JOIN route
       ON ( route.from_id = origin.id
            AND 
            route.to_id = destination.id )
 WHERE selected.id                = ?
   AND ( thread.sender_id         = ? 
         OR ( thread.recipient_id = ?
              AND ( origin.id = destination.id
                    OR ( route. distance IS NOT NULL
                         AND
                         now() >= thread.datesent
                         + ( route.distance * interval '30 seconds' )
        ))))
ORDER BY datesent ASC, thread.parent_id ASC

Замечаете проблему? Если бы SQL использовал полные имена id, вроде email_id, star_id или station_id, то баги сразу вылезали бы по мере того, как я писал этот код, а не позже, когда я пытался понять, что я сделал не так.

Сделайте себе одолжение и используйте для ID полные названия. Позднее скажете спасибо.

Давайте колонкам как можно более описательные названия. Скажем, колонка temperature никак не связана с этим:

SELECT name, 'too cold'
  FROM areas
 WHERE temperature < 32;  

Я живу во Франции, и для нас температура в 32 градуса будет «слишком холодно». Поэтому лучше назвать колонку fahrenheit.

SELECT name, 'too cold'
  FROM areas
 WHERE fahrenheit < 32;  

Теперь всё совершенно ясно.

Если у вас есть ограничения по внешним ключам, по мере возможности давайте идентичные названия колонкам на обеих сторонах ограничения. Вот идеально продуманный, разумный SQL:

SELECT *
  FROM some_table       s
  JOIN some_other_table o
    ON o.owner = s.person_id;

C этим кодом действительно всё в порядке. Но когда вы посмотрите определение таблицы, то увидите, что у some_other_table.owner есть ограничение по внешнему ключу с companies.company_id. Так что, по сути, этот SQL ошибочен. Нужно было использовать идентичные имена:

SELECT *
  FROM some_table       s
  JOIN some_other_table o
    ON o.company_id = s.person_id;

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

Однако хочу отметить, что так не всегда можно сделать. Если у вас есть таблица с исходным складом и конечным, то вы можете захотеть сравнить source_id с destination_id с warehouse_id. В таком случае лучше дать названия source_warehouse_id и destination_warehouse_id.

Также отмечу, что в приведённом примере owner будет лучше описывать назначение, чем company_id. Если вам кажется, что это приведёт к путанице, можете назвать колонку owning_company_id. Тогда название подскажет вам назначение колонки.

Этот совет известен многим опытным разработчикам баз данных, но, к сожалению, говорят о нём недостаточно часто: без уважительной причины не допускайте наличия в БД NULL-значений.
Это важная, но достаточно сложная тема. Сначала обсудим теорию, затем — её влияние на архитектуру БД, и в заключение разберём практический пример серьёзных проблем, вызванных наличием NULL-значений.

Типы баз данных

В базе могут быть данные разных типов: INTEGER, JSON, DATETIME и т. д. Тип ассоциирован с колонкой и любое добавленное в неё значение должно соответствовать этому типу.

Но что такое тип? Это наименование, набор допустимых значений и набор допустимых операций.
first type: String
second type: int
Даже если вы не замечаете, что current > threshold сравнивает не сравнимые типы, компилятор это выловит за вас.

По иронии, базы данных, которые хранят ваши данные — и являются вашей последней линией обороны от повреждения данных — ужасно работают с типами! Просто отвратительно. Например, если в вашей таблице customers есть суррогатный цифровой ключ, вы можете сделать так:

SELECT name, birthdate
  FROM customers
 WHERE customer_id > weight;

Конечно, в этом нет смысла и в реальности вы получите ошибку компилирования. Многие языки программирования облегчают вылавливание подобных ошибок типов, но с базами данных всё наоборот.

Это нормальная ситуация в мире БД, вероятно, потому, что первый стандарт SQL вышел в 1992-м. В те годы компьютеры были медленными, и всё, что усложняло реализацию, несомненно замедляло и базы данных.

И тут на сцене появляются NULL-значения. SQL-стандарт правильно реализовал их только в одном месте, в предикатах IS NULL и IS NOT NULL. Поскольку NULL-значение по определению неизвестно, у вас не может быть разработанных для него операторов. И поэтому существуют IS NULL и IS NOT NULL вместо = NULL и != NULL. А любое сравнение NULL-значений приводит к появлению нового NULL-значения.

Если для вас это звучит странно, то станет куда проще, если вы напишете «unknown» вместо NULL:

Сравнение NULL неизвестных значений приводит к появлению NULL неизвестных значений.

Ага, теперь понятно!

Что означает NULL-значение?

Вооружившись крохами теории, рассмотрим её практические следствия.

Вам нужно выплатить бонус в $500 всем сотрудникам, чья зарплата за год составила больше $50 тыс. Вы пишете такой код:

SELECT employee_number, name
  FROM employees
 WHERE salary > 50000;

И вас только что уволили, потому что ваш начальник заработал больше $50 тыс. , но его зарплата отсутствует в БД (в колонке employees.salary стоит NULL), а оператор сравнения не может сравнивать NULL с 50 000.

А почему в этой колонке есть NULL? Может быть, зарплата конфиденциальна. Может быть, информация ещё не поступила. Может быть, это консультант и не получает зарплату. Может быть, у него почасовая оплата, а не зарплата. Есть много причин, почему данные могут отсутствовать.

Наличие или отсутствие информации в колонке предполагает, что это зависит от чего-то другого, а не от денормализации первичного ключа и базы данных. Таким образом, колонки, в которых могут быть NULL-значения, являются хорошими кандидатами для создания новых таблиц. В таком случае у вас могут быть таблицы зарплата, почасовая_оплата, не_твоё_дело и т. д. Вы всё ещё уволены за слепое объединение зарплат и отсутствие таковой у вашего начальника. Но зато ваша база начинает предоставлять вам достаточно информации, чтобы вы предположили, что проблема представляет собой нечто большее, чем вопрос с зарплатами.

И да, это был глупый пример, но он стал последней каплей.

NULL-значения приводят к логически невозможным ситуациям

Вам может показаться, что я педантичен в отношении NULL-значений. Однако давайте рассмотрим ещё один пример, который гораздо ближе к реальности.

Несколько лет назад я работал в Лондоне на регистратора доменов и пытался понять, почему 80-строчный SQL-запрос возвращает некорректные данные. В той ситуации информация однозначно должна была возвращаться, но этого не происходило. Стыдно признать, но у меня ушёл день на то, чтобы понять, что причиной была такая комбинация условий:

• Я использовал OUTER JOIN.
• Они легко могли генерировать NULL-значения.
• NULL-значения могут привести к тому, что SQL даст некорректный ответ.

Многие разработчики не знают о последнем аспекте, поэтому давайте обратимся к примеру из книги Database In Depth. Простая схема из двух таблиц:

suppliers

parts
Трудно подобрать более простой пример.

Этот код возвращает p1.

SELECT part_id
  FROM parts;

А что сделает этот код?

SELECT part_id
  FROM parts
 WHERE city = city;

Он ничего не вернёт, потому что нельзя сравнивать NULL-значение, даже с другим NULL или тем же самым NULL. Это выглядит странно, потому что город в каждой строке должен быть одним и тем же, даже если мы его не знаем, правильно? Тогда что вернёт следующий код? Попробуйте это понять, прежде чем читать дальше.

SELECT s.supplier_id, p.part_id
  FROM suppliers s, parts p
 WHERE p.city <> s.city
    OR p.city <> 'Paris';

Мы не получили в ответ строки, потому что не можем сравнивать город NULL (p.city), и поэтому ни одна из веток условия WHERE не приведёт к true.

Однако мы знаем, что неизвестный город либо Париж, либо не Париж. Если это Париж, то первое условие будет истинным (<> 'London'). Если это не Париж, то истинным будет второе условие (<> 'Paris'). Таким образом, условие WHERE должно быть true, но оно им не является, и в результате SQL генерирует логически невозможный результат.

Это был баг, с которым я столкнулся в Лондоне. Каждый раз, когда вы пишете SQL, который может генерировать или содержать NULL-значения, вы рискуете получить ложный результат. Такое бывает нечасто, но очень трудно выявляется.

• Используйте имена_с_подчёркиванием вместо CamelCase.
• Имена таблиц должны быть во множественном числе.
• Давайте расширенные названия для полей с идентификаторами (item_id вместо id).
• Избегайте неоднозначных названий колонок.
• По мере возможности именуйте колонки с внешними ключами так же, как колонки, на которые они ссылаются.
• По мере возможности добавляйте NOT NULL во все определения колонок.
• По мере возможности избегайте написания SQL, который может генерировать NULL-значения.

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

НОУ ИНТУИТ | Лекция | Стандарты языка SQL

Аннотация: В лекции обсуждаются вопросы стандартизации языка SQL.

Стандартизация управления и обмена данными.

Язык SQL предназначен для доступа к информации и управления реляционной базой данных. Управление различными реляционными базами данных осуществляют программы, называемые СУБД — системы управления базами данных (DBMS — DataBase Management System). Сама реляционная база данных представляет собой хранилище определенным образом организованной информации и СУБД. Однако на практике термин СУБД часто заменяют термином БД (База Данных). Для того чтобы c различными базами данных — такими как Oracle, Microsoft SQL Server, Informix, DB2, Access, MySQL — можно было общаться на одном языке, был разработан язык SQL.

Начиная с 1986 года, комитеты ISO (International Organization for Standardization) и ANSI (American National Standards Institute) приступили к созданию ряда стандартов языка SQL, которые впоследствии были приняты и получили следующие названия: SQL86, SQL89, SQL92 и SQL99.

Стандарт SQL86 зафиксировал минимальный стандартный синтаксис языка SQL.

Стандарт SQL89 был принят в 1989 году. Он вводил набор операторов языка SQL, которые должны были реализовывать все СУБД, заявляющие поддержку стандарта SQL89. На практике каждая реальная коммерческая СУБД предоставляет значительно более широкий набор возможностей, чем предусмотрено стандартом. Так, несмотря на то, что большинство СУБД на момент принятия стандарта уже поддерживали встроенный и динамический SQL, в стандарте SQL89 правила встраивания языка SQL в процедурный язык программирования (такой как язык С) и правила использования динамического SQL прописаны не были.

До последнего времени большинство СУБД поддерживали стандарт SQL92.

В стандарте SQL92 было определено три уровня соответствия:

• основной (Entry) ;
• средний (Intermediate) ;
• полный (Full).

При этом, для того чтобы объявить СУБД поддерживающей стандарт SQL92, большинство производителей реализовывали только основной уровень соответствия.

Новый стандарт SQL99, при разработке именовавшийся как SQL3, стандартизировал объектные расширения языка SQL и некоторые процедурные расширения языка SQL. К моменту принятия этого стандарта большинство коммерческих СУБД, таких как Oracle, уже де-факто ввели использование объектных типов и наследования.

intuit.ru/2010/edi»>В стандарте SQL99 определено обязательное функциональное ядро (Core) и набор уровней расширенного соответствия. Функциональное ядро SQL99 включает в себя основной уровень соответствия SQL92. Уровни расширенного соответствия не являются обязательными для реализации в СУБД, претендующей на поддержку стандарта SQL99. СУБД может не поддерживать ни одного уровня расширенного соответствия или поддерживать любые из них.

Каждый уровень описывает набор возможностей языка SQL, которые должны поддерживать реализации СУБД, претендующие на данный уровень соответствия.

При этом объявлено, что стандарт SQL99 является открытым для всех последующих уровней расширенного соответствия, которые могут появиться в дальнейшем.

В настоящий момент стандарт SQL99 содержит следующие уровни соответствия:

• Функциональное ядро.

  Данный уровень является обязательным для любой реализации СУБД. Он включает в себя основной уровень соответствия SQL92, а также поддержку работы с LOB-объектами (Large Object), вызов из SQL внешних программ, написанных на других языках программирования, и простые типы данных, определяемые пользователем (UDT-типы, User-Defined Datatypes). Вводится поддержка LOB-объектов двух типов: бинарных BLOB-объектов (Binary Large Object) и символьных CLOB-объектов (Character Large Object). Для доступа к LOB-объектам вводятся объекты, называемые локаторами. Локаторы описываются целочисленными переменными, реализующими доступ к LOB-объекту по ссылке. Внешние программы определяются как объекты схемы, так же, как и таблицы. В зависимости от реализации сам код внешней программы может находиться в DLL-библиотеке или в произвольном файле,
  а внешняя программа создается оператором языка CREATE PROCEDURE или CREATE FUNCTION с обязательным указанием фраз LANGUAGE и EXTERNAL. Следует отметить, что хотя использование внешних программ входит в функциональное ядро, но поддержка вызова процедур и функций SQL относится к расширенному уровню соответствия » PSM -модули» (Persistent Stored Module). Определяемые пользователем типы данных могут быть простыми и структурированными. Второй случай относится к уровню соответствия «Базовая поддержка объектов». Простой тип данных, определяемый пользователем — это существующий тип данных, для которого определено новое имя и возможно некоторое ограничение по количеству символов или цифр. Простой тип данных, определяемый пользователем, создается оператором CREATE TYPE (например, CREATE TYPE name_of_new_type AS INTEGER (5) FINAL; ).

• Поддержка работы с датой/временем.

  Этот уровень соответствия вводит типы данных DATETIME и INTERVAL, а для типа DATETIME вводит поля TIMEZONE_HOUR и TIMEZONE_MINUTE, определяющие смещение для зонального времени относительно универсального времени. В стандарте SQL92 полного уровня соответствия типы данных DATETIME и INTERVAL уже были специфицированы.

• Управление целостностью.

  Этот уровень соответствия вводит поддержку дополнительных возможностей ссылочной целостности: подзапросы в ограничениях целостности CHECK оператора CREATE TABLE, триггеры, утверждения, создаваемые оператором CREATE ASSERTION. Большинство из этих возможностей входило в стандарт SQL92.

• Активные базы данных.

  На этом уровне соответствия определяется поддержка триггеров базы данных, хранимых в базе данных и выполняемых. Триггеры представляют собой фрагменты кода, выполняемые перед или после указанного изменения данных (такого как вставка строки, удаление или изменение строки).

• OLAP.

  Этот уровень соответствия определяет средства описания более сложных запросов. Так, в оператор SELECT включена фраза INTERSECT, позволяющая получать пересечения множеств, выданных несколькими запросами. В стандарте SQL92 эта возможность прописывалась только для полного уровня соответствия. В оператор SELECT включена фраза FULL OUTER JOIN, предназначенная для создания полных внешних соединений таблиц.
  Такое соединение будет содержать все строки из объединяемых таблиц, в которых при отсутствии совпадений проставляются NULL-значения. Подобная возможность была предусмотрена и в полном уровне соответствия стандарта SQL92. В операторах языка SQL, применяемых для манипулирования данными, определяется поддержка использования конструкторов значений строк и таблиц. Конструкторы значений строк состоят из одного или нескольких выражений (например, (NULL,1,’Field1′) ). Конструкторы значений таблиц представляют собой набор значений конструкторов строк, описывающий группу строк (например, VALUES (1,’A’), (2,’B’) ).

• PSM-модули.

  Этот уровень соответствия полностью описан в документе SQL/PSM стандарта SQL99. Так, язык SQL расширяется операторами управления CASE, IF, WHILE, REPEAT, LOOP и FOR. Вводится поддержка процедур и функций, создаваемых операторами CREATE PROCEDURE и CREATE FUNCTION. В язык SQL введено использование переменных и применение обработчиков ошибок.

• CLI-интерфейс.

  Этот уровень соответствия вводит поддержку интерфейса уровня вызова, определяющего вызов операторов SQL. В свое время на базе CLI -интерфейса был разработан стандарт ODBC, который более подробно будет рассматриваться в последующих лекциях.

• Базовая поддержка объектов (Basic Object Support).

  Этот уровень соответствия стандартизирует использование объектов, вводя поддержку объектных типов данных, определяемых пользователем, применение типизированных таблиц (таблиц на базе объектных типов), использование массивов и ссылочных типов данных, а также переопределение внешних процедур.

• Расширенная поддержка объектов (Enhanced Object Support).

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

Представленные выше уровни расширенного соответствия напрямую не связаны с документами, соответствующими разделам стандарта. В настоящее время стандарт SQL99 содержит следующие основные разделы:

• SQLFramework — описывает логические основы стандарта.
• SQLFoundation — определяет содержание каждого раздела стандарта и описывает функциональное ядро стандарта (Core SQL99 ).
• SQL/CLI — описывает интерфейс уровня вызова.
• SQL/PSM — определяет процедурные расширения языка SQL.
• SQL/Bindings — определяет механизм взаимодействия языка SQL с другими языками программирования.
• SQL/MM — описываются средства языка SQL, предназначенные для работы с мультимедийными данными.
• SQL/OLB — определяет связь SQL с объектными языками, описывая 0-часть стандарта SQLJ для встраивания операторов SQL в язык Java.

PostgreSQL : Документация: 12: Приложение D. Соответствие стандарту SQL : Компания Postgres Professional

Приложение D. Соответствие стандарту SQL

В этом разделе в общих чертах отмечается, в какой степени PostgreSQL соответствует текущему стандарту SQL. Следующая информация не является официальным утверждением о соответствии, а представляет только основные аспекты на уровне детализации, достаточно полезном и целесообразном для пользователей.

Формально стандарт SQL называется ISO/IEC 9075 «Database Language SQL» (Язык баз данных SQL). Время от времени выпускается обновлённая версия стандарта; последняя версия стандарта вышла в 2016 г. Эта версия получила обозначение ISO/IEC 9075:2016, или просто SQL:2016. До этого были выпущены версии SQL:2011, SQL:2008, SQL:2006, SQL:2003, SQL:1999 и SQL-92. Каждая следующая версия заменяет предыдущую, так что утверждение о совместимости с предыдущими версиями не имеет большой ценности. Разработчики PostgreSQL стремятся обеспечить совместимость с последней официальной версией стандарта, оставаясь при этом в рамках традиционной функциональности и здравого смысла. PostgreSQL реализует большую часть требуемой стандартом функциональности, хотя иногда с немного другими функциями или синтаксисом. Можно ожидать, что со временем степень совместимости будет увеличиваться.

SQL-92 определяет три уровня функциональной совместимости: начальный (Entry), промежуточный (Intermediate) и полный (Full). Большинство СУБД заявляют о совместимости со стандартом SQL только на начальном уровне, так как полный набор возможностей на промежуточном и полном уровнях либо слишком велик, либо конфликтует с ранее принятым поведением.

Начиная с SQL:1999, вместо трёх чрезмерно пространных уровней SQL-92 в стандарте SQL определено множество отдельных функциональных возможностей. Большое его подмножество представляет «Основную» функциональность, которую должны обеспечивать все совместимые с SQL реализации. Поддержка остальных возможностей не является обязательной. Некоторые необязательные возможности группируются вместе, образуя «пакеты», о поддержке которых могут заявлять реализации SQL, таким образом, декларируя совместимость с определённой группой возможностей.

Описание стандарта, начиная с версии SQL:2003, также разделяется на несколько частей. Каждая такая часть имеет короткое имя и номер. Заметьте, что нумерация этих частей непоследовательная.

• ISO/IEC 9075-1 Структура (SQL/Framework)

• ISO/IEC 9075-2 Основа (SQL/Foundation)

• ISO/IEC 9075-3 Интерфейс уровня вызовов (SQL/CLI)

• ISO/IEC 9075-4 Модули постоянного хранения (SQL/PSM)

• ISO/IEC 9075-9 Управление внешними данными (SQL/MED)

• ISO/IEC 9075-10 Привязки объектных языков (SQL/OLB)

• ISO/IEC 9075-11 Схемы информации и определений (SQL/Schemata)

• ISO/IEC 9075-13 Программы и типы, использующие язык Java (SQL/JRT)

• ISO/IEC 9075-14 Спецификации, связанные с XML (SQL/XML)

Ядро PostgreSQL реализует части 1, 2, 9, 11 и 14. Часть 3 реализуется драйвером ODBC, а часть 13 — подключаемым расширением PL/Java, но точное соответствие этих компонентов стандарту на данный момент не проверено. Части 4 и 10 в PostgreSQL в настоящее время не реализованы.

PostgreSQL поддерживает почти все основные возможности стандарта SQL:2016. Из 179 обязательных возможностей, которые требуются для полного соответствия «Основной» функциональности, PostgreSQL обеспечивает совместимость как минимум для 160. Кроме того, он реализует длинный список необязательных возможностей. Следует отметить, что на время написания этой документации ни одна существующая СУБД не заявила о полном соответствии «Основной» функциональности SQL:2016.

В следующих двух разделах мы представляем список возможностей, которые поддерживает PostgreSQL, и список возможностей, определённых в SQL:2016, которые ещё не поддерживаются в PostgreSQL. Оба эти списка носят приблизительный характер: какая-то возможность, отмеченная как поддерживаемая, может отличаться от стандарта в деталях, и напротив, для какой-то неподдерживаемой возможности могут быть реализованы ключевые компоненты. Наиболее точная информация о том, что работает, а что нет, содержится в основной документации.

Примечание

Коды возможностей, содержащие знак минус, обозначают подчинённые возможности. При этом, если какая-либо одна подчинённая возможность не поддерживается, основная возможность так же не будет поддерживаться, даже если реализованы все остальные на подуровне.

Postgres Pro Standard : Документация: 9.5: Приложение D. Соответствие стандарту SQL : Компания Postgres Professional

Приложение D. Соответствие стандарту SQL

В этом разделе в общих чертах отмечается, в какой степени Postgres Pro соответствует текущему стандарту SQL. Следующая информация не является официальным утверждением о соответствии, а представляет только основные аспекты на уровне детализации, достаточно полезном и целесообразном для пользователей.

Формально стандарт SQL называется ISO/IEC 9075 «Язык баз данных SQL». Время от времени выпускается обновлённая версия стандарта; последняя версия стандарта вышла в 2011 г. Эта версия получила обозначение ISO/IEC 9075:2011, или просто SQL:2011. До этого были выпущены версии SQL:2008, SQL:2003, SQL:1999 и SQL-92. Каждая следующая версия заменяет предыдущую, так что утверждение о совместимости с предыдущими версиями не имеет большой ценности. Разработчики Postgres Pro стремятся обеспечить совместимость с последней официальной версией стандарта, оставаясь при этом в рамках традиционной функциональности и здравого смысла. Postgres Pro реализует большую часть требуемой стандартом функциональности, хотя иногда с немного другими функциями или синтаксисом. Можно ожидать, что со временем степень совместимости будет увеличиваться.

SQL-92 определяет три уровня функциональной совместимости: начальный (Entry), промежуточный (Intermediate) и полный (Full). Большинство СУБД заявляют о совместимости со стандартом SQL только на начальном уровне, так как полный набор возможностей на промежуточном и полном уровнях либо слишком велик, либо конфликтует с ранее принятым поведением.

Начиная с SQL:1999, вместо трёх чрезмерно пространных уровней SQL-92 в стандарте SQL определено множество отдельных функциональных возможностей. Большое его подмножество представляет «Основную» функциональность, которую должны обеспечивать все совместимые с SQL реализации. Поддержка остальных возможностей не является обязательной. Некоторые необязательные возможности группируются вместе, образуя «пакеты», о поддержке которых могут заявлять реализации SQL, таким образом, декларируя совместимость с определённой группой возможностей.

Описание стандарта, начиная с версии SQL:2003, также разделяется на несколько частей. Каждая такая часть имеет короткое имя и номер. Заметьте, что нумерация этих частей непоследовательная.

• ISO/IEC 9075-1 Структура (SQL/Framework)

• ISO/IEC 9075-2 Основа (SQL/Foundation)

• ISO/IEC 9075-3 Интерфейс уровня вызовов (SQL/CLI)

• ISO/IEC 9075-4 Модули постоянного хранения (SQL/PSM)

• ISO/IEC 9075-9 Управление внешними данными (SQL/MED)

• ISO/IEC 9075-10 Привязки объектных языков (SQL/OLB)

• ISO/IEC 9075-11 Схемы информации и определений (SQL/Schemata)

• ISO/IEC 9075-13 Программы и типы, использующие язык Java (SQL/JRT)

• ISO/IEC 9075-14 Спецификации, связанные с XML (SQL/XML)

Ядро Postgres Pro реализует части 1, 2, 9, 11 и 14. Часть 3 реализуется драйвером ODBC, а часть 13 — подключаемым расширением PL/Java, но точное соответствие этих компонентов стандарту на данный момент не проверено. Части 4 и 10 в Postgres Pro в настоящее время не реализованы.

Postgres Pro поддерживает почти все основные возможности стандарта SQL:2011. Из 179 обязательных возможностей, которые требуются для полного соответствия «Основной» функциональности, Postgres Pro обеспечивает совместимость как минимум для 160. Кроме того, он реализует длинный список необязательных возможностей. Следует отметить, что на время написания этой документации ни одна существующая СУБД не заявила о полном соответствии «Основной» функциональности SQL:2011.

В следующих двух разделах мы представляем список возможностей, которые поддерживает Postgres Pro, и список возможностей, определённых в SQL:2011, которые ещё не поддерживаются в Postgres Pro. Оба эти списка носят приблизительный характер: какая-то возможность, отмеченная как поддерживаемая, может отличаться от стандарта в деталях, и напротив, для какой-то неподдерживаемой возможности могут быть реализованы ключевые компоненты. Наиболее точная информация о том, что работает, а что нет, содержится в основной документации.

Примечание

Коды возможностей, содержащие знак минус, обозначают подчинённые возможности. При этом, если какая-либо одна подчинённая возможность не поддерживается, основная возможность так же не будет поддерживаться, даже если реализованы все остальные на подуровне.

Конвертация Базы данных из SQL Server Express в SQL Server Standart — Контур.Экстерн

При достижении базы с типом SQL Server Express размера 10 ГБ вы не сможете отправлять и получать документы, поскольку это максимально допустимый размер базы для этого типа.

При большом размере базы данных SQL Server Express воспользуйтесь одним из вариантов:

Перенесите базу данных в SQL Server Standart

Рекомендуется, чтобы перенос базы и настройку сделал ваш системный администратор, с учетом специфики доменной политики, размещения серверов, политики аутентификации.

1.Создайте и сохраните Backup базы данных, которая находится на SQL Server Express.

2. Установите и настройте SQL Server редакции выше чем Express (например, редакции Standart или Developer).

3. В установленной редакции SQL Server восстановите базу данных из созданного в п.1. Backup-а.

4. Настройте Контур.Экстерн Лайт на работу с базой в установленной редакции SQL Server согласно инструкции. Укажите новые имя сервера и параметры аутентификации, если они изменились.

Создайте новую базу данных SQL Server Express (временное решение)

Воспользуйтесь данным вариантом, если у вас по каким-то причинам нет возможности перенести базу из SQL Server Express в SQL Server Standart. При этом старых отчетов в новой базе не будет.

1. Выберите в Контур.Экстерн Лайт меню «Настройки / Параметры соединения с базой данных…».

2. В строке «Имя базы данных:» впишите новое имя файла: например, RSBase2.sdf вместо RSBase.sdf:

3. Нажмите «Сохранить» и перезапустите Контур.Экстерн Лайт. После перезапуска добавьте пользователя.

4. При первом нажатии «Отправить и получить», Контур.Экстерн Лайт предложит скачать все документа с сервера. Выберите ползунком не все документы, а за определенный период: например, начиная с текущего месяца (либо за более ранний период при необходимости) и нажмите «ОК».

Microsoft SQL Server 2017, 2019

Call-Центр

Москва:

Санкт-Петербург:

Бесплатно по всей РФ:

Время работы Call-Центра:

Пн-Пт: с 09:00 до 19:00

Пятница: с 9:00 до 18:00

Сб, Вск — выходные дни

Точки самовывоза

Москва

117335 г. Москва, Архитектора Власова д. 6

Время работы:

Пн-Пт: с 09:00 до 19:00

Пятница: с 9:00 до 18:00

Сб, Вск — выходные дни

Санкт-Петербург

196084, г. Санкт-Петербург, ул. Малая Митрофаньевская, д.4, лит. А, офис 401

Время работы:

Пн-Пт: с 09:00 до 19:00

Пятница: с 9:00 до 18:00

Сб, Вск — выходные дни

Услуги и поддержка

Отзывы ЯндексМаркет:

Мы в соц. сетях:

ПО по подписке (электронно) Microsoft SQL Server Standard 2 Core License Pack 1 year

SQL Server: Standard Edition vs Enterprise Edition — Консультации по SQL Server

Вам нужен SQL Server Enterprise Edition? Может быть. Возможно, нет. В последнее время мы находим все больше и больше людей, которые могут ответить на этот вопрос , вероятно, нет. Я потерял счет количества клиентов, которым мы помогли перейти с SQL Server Enterprise на SQL Server Standard, воспользоваться преимуществами новых функций и значительно сократить их расходы. Я только что провел сегодня вебинар, об этом говорили SIOS Technologies и Дэвид Бермингем.Я поделюсь видео с MSSQLTIPS здесь завтра, когда у нас будет ссылка, и как только я получу список вопросов, на которые мы не ответили, я отвечу на них здесь в своем сообщении завтра.

А пока небольшой пост, в котором я расскажу о некоторых вещах, о которых стоит подумать, о некоторых причинах, по которым стоит подумать о переходе на стандартную версию, о некоторых причинах остаться в Enterprise. Завтра я поделюсь ссылкой на веб-семинар и подробнее расскажу о достижении высокой доступности с помощью стандарта SQL Server в облаке.

Ответы здесь не универсальны.Некоторым людям нужно остаться на предприятии SQL Server. Некоторым следует ускорить переход с SQL Server Enterprise на SQL Server Standard.

Зачем переходить на SQL Server Standard Edition?

Экономия $ 10 000 на каждом пакете из 2 ядер — хороший повод для начала. На 8-ядерном сервере — это 40 000 причин. И это без Software Assurance (это отдельная тема для другого поста — навигация по Software Assurance и лицензированию)

Дело не только в деньгах.Позвольте мне сформулировать это так: «Почему бы и нет?» Конечно, есть несколько причин оставаться на Enterprise (см. Ниже), но многие из причин, которые мы раньше приводили без особых размышлений, больше не являются уважительными. Вот только или вещей, которые мы получаем со стандартом SQL Server в настоящее время в SQL Server 2019:

• ОЗУ 128 ГБ — по сравнению с 64 ГБ в SQL Server 2012 и ниже.
• 24 ядра (или 4 сокета, в зависимости от того, что меньше) — с 16 ядер в SQL Server 2014
• Отказоустойчивый кластер с двумя узлами (один экземпляр) для обеспечения высокой доступности (подробнее об этом завтра — в том числе о том, как мы делаем это с большим количеством клиентов в облака)
• Группы доступности (с некоторыми ограничениями, начиная с SQL Server 2016)
• Сжатие (данные с 2016 SP1 и резервные копии намного дольше)
• Шифрование (резервное копирование, TDE, Always Encrypted) — TDE / Always Encrypted — это новинка SQL Server 2019
• Разбиение на разделы
• Хранилище запросов
• Все функции безопасности (постоянное шифрование, аудит сервера и БД, EKM, шифрование резервных копий, динамическое маскирование данных и т. Д.))

Более подробная информация представлена ​​здесь, в матрице функций выпусков для SQL Server 2019. Вы можете щелкнуть ссылки, чтобы увидеть эволюцию с 2017/2017/2014 и более ранних версий.

Короче говоря — если ваша рабочая нагрузка может обрабатывать 128 ГБ ОЗУ или меньше, 24 ядра или меньше — и вам не нужны несколько корпоративных функций, описанных ниже — возможно, вам действительно стоит рассмотреть SQL Server Standard. Это может быть даже проще проверить, чем вы думаете, с виртуальными машинами и облачными средами!

Приложив довольно небольшие усилия, мы сэкономили нескольким клиентам примерно 60 000–80 000 долларов в год на их лицензировании AWS, переведя их из групп доступности в Enterprise Edition в экземпляры отказоустойчивого кластера в SQL Server Standard.

Нужен ли мне SQL Server Enterprise Edition?

Если вам действительно нужны некоторые из ориентированных на производительность функций, которые есть в Enterprise Edition, имеет смысл остаться на этом уровне. Если вам нужно более 128 ГБ ОЗУ или более 24 ядер, это тоже необходимо.

Некоторые вещи, которые вы упускаете из виду (ссылка выше покажет полный список) при переходе на стандартную версию:

• Online Index Rebuilds (но мы не думаем, что вам следует перестраивать индексы так часто, как вы, вероятно, делаете, и мы не думаем, что вам следует перестраивать, когда фрагментация настолько мала, насколько вы, вероятно, перестраиваете)
• Регулятор ресурсов
• Некоторые из расширенных функций ядра, которые обеспечивают лучшее масштабирование Enterprise Edition (например, чтение с упреждающим чтением и другие оптимизации на уровне хранилища — хотя и с хорошо настроенной базой данных на твердом вводе-выводе — для среды БД, которая умещается в 128 ГБ ОЗУ — это может быть не такая большая проблема, как вы опасаетесь)
• Группы доступности с читаемыми вторичными компонентами (хотя — для них требуется, чтобы вы знали ДВА экземпляра SQL Server корпоративной редакции.Если вам на 100% нужна эта функция и все, что она дает — тогда вам нужен Enterprise. Но — можно ли обойтись ночным восстановлением? Или, если вам нужна более свежая информация, может ли работать репликация транзакций? Это не так страшно, как кажется — и вы можете выполнить репликацию на вторичную версию Standard Edition, и вы даже можете добавить индексы для отчетности только по подписчику — в отличие от AG)
• Многоузловые FCI
• Подробнее см. В приведенном выше списке.

Конечно. Со стандартной версией вы отказываетесь от некоторых вещей.И некоторым людям действительно нужны эти создатели различий. Но в SQL Server 2017 одним из тех факторов, которые определяли разницу, было «TDE необходим аудиторам» — теперь этого больше нет. В RTM SQL Server 2016 одним из факторов, определяющих разницу, было «Сжатия нет» — этого не было в качестве оправдания с момента выхода SQL Server 2016 SP1

.

Итак, что вам делать?

У меня, наверное, есть блок-схема, которая начинается с:

1. Вам нужно более 128 ГБ ОЗУ? (гораздо больше — я не имею в виду 192 или 144 ГБ — этого может быть достаточно, чтобы проверить, сможете ли вы выполнить некоторую настройку и оптимизацию)
2. Если нет — вам нужно более 24 ядер?
3. Если нет — нужна ли вам вторичная функция только для чтения в AG или трехузловая HA / DR в одном решении?
4. Если нет — действительно ли вам нужно перестроить онлайн-индексы (и если ответ положительный — перестраиваете ли вы все индексы каждую неделю, независимо от того, нужно им это или нет? Если нет, это недостаточно хорошее оправдание)

Если вы продолжали получать «Нет ответов» — вы должны увидеть, что происходит с SQL Server Standard в тестовой среде.Если у вас 144 или 192 ГБ ОЗУ — посмотрите, что произойдет, если вы уменьшите максимальную память SQL больше — или уменьшите виртуальную машину, на которой вы работаете, до 128 ГБ — или переместите свою облачную инфраструктуру до размера, более подходящего для стандарта, — что произошло? Как прошли тесты?

И не забывайте — с экономией — вы можете потратить больше времени на настройку своей БД, вы можете потратить больше бюджета на размышления о масштабируемой архитектуре, вы можете подумать об использовании таких вещей, как FCI + Log Shipping для обеспечения HA + DR и оставайтесь на стандарте и получите свою «включенную пару высокой доступности» и третий SQL-сервер аварийного восстановления.”

Еще завтра, когда я надеюсь поделюсь ссылкой на запись и некоторыми ответами на вопросы. На сегодняшнем веб-семинаре говорилось немного больше о FCI в стандарте SQL Server и использовании инструментов репликации на уровне блоков; SIOS Datakeeper — это инструмент, который мы предпочитаем, хотя есть и другие.

Как вы думаете? Можете ли вы сэкономить деньги своей компании один раз? Или вы можете вдвое сократить расходы на облачные вычисления на стороне SQL Server? Я видел, как люди это делают, и мне всегда хочется, чтобы мы включили в наши контракты бонусную оговорку «Процент экономии лицензий»!

Напишите мне через контактные формы на сайте, если у вас есть быстрый вопрос о вашей среде.Мы очень заняты, и я не могу дать вам полную архитектуру и план миграции по электронной почте, но я могу по крайней мере указать вам правильное направление и начать работу!

PostgreSQL: Документация: 12: Приложение D. Соответствие SQL

Приложение D. Соответствие SQL

В этом разделе делается попытка определить, в какой степени PostgreSQL соответствует текущему стандарту SQL. Следующая информация не является полным заявлением о соответствии, но она представляет основные темы настолько подробно, насколько это разумно и полезно для пользователей.

Официальное название стандарта SQL — ISO / IEC 9075 «Язык баз данных SQL». Время от времени выпускается пересмотренная версия стандарта; самое последнее обновление появилось в 2016 году. Версия 2016 года упоминается как ISO / IEC 9075: 2016 или просто как SQL: 2016. Предыдущие версии были SQL: 2011, SQL: 2008, SQL: 2006, SQL: 2003, SQL: 1999 и SQL-92. Каждая версия заменяет предыдущую, поэтому заявления о соответствии более ранним версиям не имеют официальных оснований. Разработка PostgreSQL нацелена на соответствие последней официальной версии стандарта, где такое соответствие не противоречит традиционным функциям или здравому смыслу.Поддерживаются многие функции, требуемые стандартом SQL, хотя иногда и с немного другим синтаксисом или функцией. Со временем можно ожидать дальнейшего продвижения к соответствию.

SQL-92 определил три набора функций для соответствия: начальный, промежуточный и полный. Большинство систем управления базами данных, заявляющих о соответствии стандарту SQL, соответствовали только на начальном уровне, поскольку весь набор функций на промежуточном и полном уровнях был либо слишком объемным, либо противоречил устаревшему поведению.

Начиная с SQL: 1999, стандарт SQL определяет большой набор отдельных функций, а не неэффективно широкие три уровня, как в SQL-92. Большая часть этих функций представляет собой «основные» функции, которые должна предоставлять каждая соответствующая реализация SQL. Остальные функции являются необязательными. Некоторые дополнительные функции сгруппированы вместе, чтобы сформировать «пакеты», соответствие которым реализации SQL могут утверждать, таким образом заявляя о соответствии определенным группам функций.

Стандартные версии, начиная с SQL: 2003, также разделены на несколько частей. Каждый известен под сокращенным именем. Обратите внимание, что эти части не пронумерованы последовательно.

• Структура ISO / IEC 9075-1 (SQL / Framework)

• ISO / IEC 9075-2 Foundation (SQL / Foundation)

• ISO / IEC 9075-3 Интерфейс уровня вызовов (SQL / CLI)

• ISO / IEC 9075-4 Модули постоянного хранения (SQL / PSM)

• ISO / IEC 9075-9 Управление внешними данными (SQL / MED)

• Привязки объектного языка ISO / IEC 9075-10 (SQL / OLB)

• Информационные схемы и схемы определений ISO / IEC 9075-11 (SQL / Schemata)

• ISO / IEC 9075-13 Процедуры и типы с использованием языка Java (SQL / JRT)

• ISO / IEC 9075-14 Спецификации, связанные с XML (SQL / XML)

Ядро PostgreSQL охватывает части 1, 2, 9, 11 и 14.Часть 3 покрывается драйвером ODBC, а часть 13 покрывается подключаемым модулем PL / Java, но точное соответствие для этих компонентов в настоящее время не проверяется. В настоящее время нет реализаций частей 4 и 10 для PostgreSQL.

PostgreSQL поддерживает большинство основных функций SQL: 2016. Из 179 обязательных функций, необходимых для полного соответствия Core, PostgreSQL соответствует как минимум 160. Кроме того, существует длинный список поддерживаемых дополнительных функций. Возможно, стоит отметить, что на момент написания ни одна текущая версия какой-либо системы управления базами данных не заявляла о полном соответствии Core SQL: 2016.

В следующих двух разделах мы предоставляем список тех функций, которые поддерживает PostgreSQL, а затем список функций, определенных в SQL: 2016, которые еще не поддерживаются в PostgreSQL. Оба этих списка являются приблизительными: могут быть незначительные детали, которые не соответствуют функции, которая указана как поддерживаемая, и на самом деле могут быть реализованы большие части неподдерживаемой функции. Основная часть документации всегда содержит наиболее точную информацию о том, что работает, а что нет.

Примечание

Коды функций, содержащие дефис, являются подкомпонентами. Таким образом, если конкретная функция не поддерживается, основная функция указывается как неподдерживаемая, даже если поддерживаются некоторые другие функции.

MySQL :: Справочное руководство MySQL 8.0 :: Соответствие стандартам MySQL 1.7

1.7 Соответствие стандартам MySQL

В этом разделе описывается, как MySQL соотносится с ANSI / ISO SQL.
стандарты. MySQL Server имеет множество расширений стандарта SQL,
а здесь вы можете узнать, что это такое и как ими пользоваться.Ты
также можно найти информацию о функциях, отсутствующих в MySQL
Server и способы устранения некоторых различий.

Стандарт SQL развивается с 1986 года и имеет несколько версий.
существовать. В этом руководстве «SQL-92» относится к
стандарт выпущен в 1992 году. «SQL: 1999»,
«SQL: 2003», «SQL: 2008» и
«SQL: 2011» относится к версиям стандарта.
выпущены в соответствующие годы, причем последние
последняя версия.Мы используем фразу «стандарт SQL»
или «стандартный SQL» для обозначения текущей версии
Стандарт SQL в любое время.

Одна из наших основных целей с продуктом — продолжать работать
в сторону соответствия стандарту SQL, но без ущерба для
скорость или надежность. Мы не боимся добавлять расширения в SQL
или поддержка функций, отличных от SQL, если это значительно увеличивает
удобство использования MySQL Server для большого сегмента нашей пользовательской базы.
Интерфейс HANDLER является примером
этой стратегии.См. Раздел 13.2.4, «Заявление ОБРАБОТЧИКА».

Мы продолжаем поддерживать транзакционные и нетранзакционные
базы данных, чтобы удовлетворить как критически важное использование 24/7, так и тяжелые
Использование Интернета или ведения журнала.

Сервер MySQL изначально был разработан для работы со средними
базы данных (10-100 миллионов строк или около 100 МБ на таблицу) на небольших
Компьютерные системы. Сегодня MySQL Server обрабатывает файлы размером в терабайт.
базы данных.

Мы не нацелены на поддержку в реальном времени, хотя репликация MySQL
возможности предлагают значительную функциональность.

MySQL поддерживает уровни ODBC от 0 до 3.51.

MySQL поддерживает кластеризацию баз данных с высокой доступностью, используя
NDBCLUSTER накопитель. Видеть
Глава 23, MySQL NDB Cluster 8.0 .

Мы реализуем функциональность XML, которая поддерживает большую часть W3C.
Стандарт XPath. См. Раздел 12.12, «Функции XML».

MySQL поддерживает собственный тип данных JSON, как определено в RFC 7159, и
основан на стандарте ECMAScript (ECMA-262).Видеть
Раздел 11.5, «Тип данных JSON». MySQL также реализует подмножество
Функции SQL / JSON, указанные в предварительном проекте документа
SQL: стандарт 2016; см. Раздел 12.18, «Функции JSON», чтобы узнать больше.
Информация.

Выбор режимов SQL

Сервер MySQL может работать в разных режимах SQL и может применять
эти режимы по-разному для разных клиентов, в зависимости от
значение системы sql_mode
Переменная.Администраторы баз данных могут установить глобальный режим SQL в соответствии с сервером сайта.
эксплуатационные требования, и каждое приложение может установить свой сеанс
Режим SQL в соответствии с собственными требованиями.

Режимы влияют на синтаксис SQL, который поддерживает MySQL, и на проверку данных.
проверяет, выполняет ли он. Это упрощает использование MySQL в разных
среды и использовать MySQL вместе с другой базой данных
серверы.

Для получения дополнительной информации о настройке режима SQL см.
Раздел 5.1.11, «Режимы SQL сервера».

Запуск MySQL в режиме ANSI

Чтобы запустить MySQL Server в режиме ANSI, запустите mysqld
с опцией --ansi . Запуск
сервер в режиме ANSI аналогичен запуску со следующей
параметры:

  --transaction -olated = SERIALIZABLE --sql-mode = ANSI  

Чтобы добиться того же эффекта во время выполнения, выполните эти два
заявления:

  УСТАНОВИТЬ ГЛОБАЛЬНЫЙ УРОВЕНЬ ИЗОЛЯЦИИ СДЕЛКИ С СЕРИЙНЫМ УРОВНЕМ;
УСТАНОВИТЬ ГЛОБАЛЬНЫЙ sql_mode = 'ANSI';  

Вы можете видеть, что установка
sql_mode системная переменная для
'ANSI' включает все параметры режима SQL, которые
относится к режиму ANSI следующим образом:

  mysql> УСТАНОВИТЬ ГЛОБАЛЬНЫЙ sql_mode = 'ANSI';
mysql> ВЫБРАТЬ @@ ГЛОБАЛЬНЫЙ.sql_mode;
        -> 'REAL_AS_FLOAT, PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE, ANSI'  

Запуск сервера в режиме ANSI с
--ansi не совсем то же самое, что
установка режима SQL на 'ANSI' , потому что
-ansi опция также устанавливает
уровень изоляции транзакции.

См. Раздел 5.1.7, «Параметры команд сервера».

Что такое SQL

Резюме : в этом руководстве мы познакомим вас с языком SQL, обсудим стандартный SQL и некоторые популярные диалекты SQL.

Введение в язык SQL

SQL — это язык программирования, предназначенный для управления данными, хранящимися в системе управления реляционными базами данных (СУБД).

SQL — это язык структурированных запросов. Он произносится как / ˈɛs kjuː ˈɛl / или / ˈsiːkwəl /.

SQL состоит из языка определения данных, языка обработки данных и языка управления данными.

• Язык определения данных занимается созданием и изменением схемы, например, оператор CREATE TABLE позволяет вам создать новую таблицу в базе данных, а оператор ALTER TABLE изменяет структуру существующей таблицы.
• Язык манипулирования данными предоставляет конструкции для запроса данных, таких как оператор SELECT, и для обновления данных, таких как операторы INSERT, UPDATE и DELETE.
• Язык управления данными состоит из операторов, связанных с авторизацией и безопасностью пользователей, таких как операторы GRANT и REVOKE.

Стандарт SQL

SQL был одним из первых коммерческих языков баз данных с 1970 года. С тех пор различные поставщики баз данных внедрили SQL в свои продукты с некоторыми вариациями.Чтобы обеспечить большее соответствие между поставщиками, Американский институт стандартов (ANSI) опубликовал первый стандарт SQL в 1986 году.

ANSI затем обновил стандарт SQL в 1992 году, известный как SQL92 и SQL2, и снова в 1999 году как SQL99 и SQL3. Каждый раз ANSI добавлял новые функции и команды в язык SQL.

Стандарт SQL в настоящее время поддерживается как ANSI, так и международной организацией по стандартизации как стандарт ISO / IEC 9075. Последний стандарт выпуска — SQL: 2011.

Стандарт SQL формализует синтаксические структуры и поведение SQL в продуктах баз данных.Это становится еще более важным для баз данных с открытым исходным кодом, таких как MySQL и PostgreSQL, где СУБД разрабатываются в основном сообществами, а не крупными корпорациями.

Диалекты SQL

Сообщество постоянно запрашивает новые функции и возможности, которых еще нет в стандарте SQL, поэтому даже при наличии стандарта SQL существует множество диалектов SQL в различных продуктах баз данных.

Поскольку ANSI и ISO еще не разработали эти важные функции, поставщики РСУБД (или сообщества) могут свободно изобретать свою собственную новую структуру синтаксиса.

Ниже приведены наиболее популярные диалекты SQL:

В каждом учебном пособии мы объясним структуры синтаксиса SQL и поведение, действующие в базах данных. Мы также обсудим исключения, если они существуют в конкретной базе данных.

Было ли это руководство полезным?

Microsoft SQL Server 2019 Standard +5 клиентских лицензий

Стандарт SQL — SQL в двух словах [Книга]

Чтобы обеспечить большее соответствие между поставщиками,

Американец
Национальный институт стандартов (ANSI) опубликовал свой первый стандарт SQL
в 1986 году и второй широко принятый стандарт в 1989 году.Выпущен ANSI
обновления 1992 г., известные как SQL92 и
SQL2, и снова в
1999, названный как SQL99, так и SQL3. Каждый раз ANSI добавлял новые функции
и включил в язык новые команды и возможности.
Уникальной особенностью стандарта SQL99 является группа возможностей, которые позволяют
объектно-ориентированные расширения типов данных. В
Международная организация по стандартизации (ISO)
также одобрил SQL99. Важным отличием от SQL92 является то, что SQL99
расширяет уровень соответствия SQL92 .

SQL92 впервые представлен
уровни соответствия путем определения
три категории: начальный, средний и полный.Продавцы были вынуждены
достичь начального уровня
соответствие заявлению о соответствии ANSI SQL. Соединенные штаты.

Национальный институт стандартов и
Технология (NIST) позже добавила переходный уровень между входом.
и промежуточные уровни. Так,
Уровни соответствия NIST были: Входной, Переходный,
Промежуточный и полный, в то время как
ANSI были только Entry, Intermediate и Full. Каждый выше
уровень стандарта был надмножеством нижестоящего уровня,
это означает, что каждый более высокий уровень стандарта включал все
особенности нижнего уровня соответствия.

SQL99 изменен
базовые уровни соответствия. Исчезли начальные, промежуточные и
Полный уровень соответствия. С SQL99 поставщики должны реализовать все
характеристики самого низкого уровня соответствия, Core
SQL: 1999 , чтобы заявить (и опубликовать), что они
SQL99 готов.
Core SQL: 1999 — или Core SQL99,
для краткости — включает старый набор функций Entry SQL92, функции
из других уровней SQL92, а также некоторые новые функции. Это обновление до
стандарт SQL позволил поставщикам быстро перейти от Entry SQL92
набор функций для набора функций Core SQL99.

В то время как SQL92 имел промежуточный и полный уровни
соответствие, SQL99 имеет Enhanced
SQL: 1999
. Любая СУБД, поддерживающая Core SQL99
тесты, плюс один или несколько из девяти дополнительных пакетов функций,
теперь считается, что он соответствует стандартам Enhanced SQL: 1999, определенным в SQL99 (также
называется Enhanced SQL99).

Пакеты дополнительных функций

Стандарт SQL99 представляет
идеально, но очень немногие производители сразу же соответствуют требованиям Core SQL99 или превосходят их.
требования.Стандарт Core SQL99 подобен межгосударственной скорости
предел: одни драйверы идут выше, другие — ниже, но немногие идут точно
Ограничение скорости. Точно так же реализации поставщиков могут сильно различаться.

Два комитета — один в ANSI, а другой в ISO
— состоит из представителей практически всех поставщиков СУБД
составили эти определения. В этом совместном и несколько
политическая среда, поставщики должны идти на компромисс в отношении того, какой именно
предлагаемая функция и реализация будут включены в новую
стандарт.Много раз новая функция в стандарте ANSI выводится
из существующего продукта или является результатом новых исследований и
развитие со стороны академического сообщества. Следовательно, многие производители
принять некоторые функции в стандарте, а позже добавить еще больше.

Девять дополнительных пакетов функций, представляющих различные
подмножества команд не являются обязательными для поставщика. Некоторые функции SQL99 могут
появляются в нескольких пакетах, в то время как другие не появляются ни в одном из
пакеты. Эти пакеты и их функции описаны в
Таблица 1.1.

Таблица 1-1. Пакеты дополнительных функций SQL99

Имейте в виду, что поставщик СУБД может заявить о соответствии Enhanced SQL99, встретившись с Core
Стандарты SQL99 плюс только один из девяти добавленных пакетов ; поэтому прочтите мелкий шрифт продавца, чтобы
описание его программных возможностей.Понимая, какие особенности
составляют девять пакетов, программисты и разработчики получают четкое
представление о возможностях конкретной СУБД и о том, как различные
функции работают, когда код SQL переносится в другую базу данных
продукты.

ANSI
стандарты — которые охватывают поиск, манипулирование и управление
данных в командах, таких как SELECT ,
JOIN , ALTER TABLE и
DROP — формализованы многие поведения SQL и
синтаксические структуры в различных продуктах.Эти стандарты
становятся еще более важными как продукты баз данных с открытым исходным кодом, такие как
MySQL, miniSQL и PostgreSQL становятся все популярнее и разрабатываются.
виртуальными командами, а не крупными корпорациями.

SQL в двух словах объясняет SQL
реализация четырех популярных СУБД. Эти поставщики не соответствуют всем
стандарты SQL99; Фактически, все поставщики РСУБД постоянно играют в
тега с органами по стандартизации. Часто, как только продавцы
близко к стандарту, органы по стандартизации обновляют, уточняют или
в противном случае измените эталон.

Сравнение классов операторов дает дальнейшее определение
SQL92 и SQL99. В SQL92 операторы SQL сгруппированы в три
широкие категории: манипуляция данными
Язык (DML), определение данных
Язык (DDL) и Data Control
Язык (DCL). DML предоставляет конкретные
команды обработки данных, такие как SELECT ,
ВСТАВИТЬ , ОБНОВЛЕНИЕ и
УДАЛИТЬ . DDL содержит команды, которые обрабатывают
доступность и манипулирование объектами базы данных, в том числе
CREATE и DROP , а
DCL содержит команды, связанные с разрешениями GRANT
и ОТМЕНИТЬ .

Напротив, SQL99 предоставляет семь основных категорий, которые обеспечивают
общая структура для типов команд, доступных в SQL. Эти
оператор «классы» немного отличается от SQL92
классы операторов, поскольку они пытаются идентифицировать утверждения
внутри каждого класса точнее и логичнее. Кроме того, поскольку
SQL постоянно находится в разработке, появляются новые функции и команды.
стандарт и может потребовать новых классов операторов. Итак, чтобы
чтобы приспособиться к будущему росту, SQL99 разработал новые наборы инструкций
классы, делая их несколько более понятными и логичными.Кроме того, новые классы операторов теперь позволяют
«Осиротевшие» заявления, которые не вписывались в
любая из старых категорий — для правильной классификации.

В таблице 1.2 указаны классы операторов SQL99.
и перечисляет несколько команд в каждом классе, каждая из которых полностью
обсудим позже. На этом этапе важно запомнить утверждение
название класса.

Таблица 1-2. Классы операторов SQL

Тем, кто регулярно работает с SQL, следует ознакомиться с обоими
старые (SQL92) и новые (SQL99) классы операторов, поскольку многие
программисты и разработчики до сих пор используют старую номенклатуру для обозначения
текущие возможности SQL.

Стандартный SQL — TDAN.com

Опубликовано на TDAN.com Январь 2003 г.

Поддерживают ли IBM, Microsoft и Oracle стандарт SQL: 1999? И будут ли они поддерживать стандарт SQL: 2003?

Комитет

Существует международный комитет, работающий над стандартом SQL (ISO / IEC JTC 1 / SC 32 / WG 3), а также американский комитет (ANSI TC NCITS h3) — я для краткости назову их Комитетом. Комитет опубликовал несколько редакций официального стандарта SQL.Сегодня важны три издания:

.

• SQL-92 предыдущий стандарт
• SQL: 1999 текущий стандарт, также называемый SQL-99
• SQL: 2003 будущий стандарт, также называемый SQL: 200n

Большая тройка поставщиков СУБД (IBM, Microsoft, Oracle) имеет своих представителей в Комитете и утверждает, что поддерживает официальный стандарт. Общая поддержка официального стандарта прекрасна как для пользователей, так и для поставщиков, так же как общие языки и однозначные спецификации прекрасны.Я хочу показать, где «большая тройка» поддерживает стандарт, а где нет. Вы можете использовать мое описание, чтобы сделать свой код более переносимым (следуя советам), сделать себя более переносимым (зная, какие передаваемые навыки у вас есть) или сделать вашего поставщика более переносимым (настаивая на стандартах в качестве критерия проекта) .

Претензии поставщиков

Каждый поставщик делает формальное, но хитрое заявление о стандарте SQL в своей официальной документации, которую я цитирую:

«DB2 UDB SQL соответствует стандарту SQL 1999 Core.”
— Корпорация IBM, Справочник по SQL для кроссплатформенной разработки

«Функции Core SQL: 1999, которые полностью поддерживает Oracle, перечислены в Таблице B-1…»
— Oracle Corporation, Oracle9i SQL Reference

«Версия Microsoft SQL Server 2000 Transact-SQL соответствует начальному уровню стандарта SQL-92…»
— Корпорация Microsoft, Электронная документация по SQL Server 2000 (обновленная)

Вот еще одна цитата из стандартного документа SQL: 1999:

«Это издание [SQL: 1999] отменяет и заменяет третье издание [SQL / 92].”
— Стандарт SQL: 1999

Другими словами, Комитет утверждает, что Microsoft поддерживает несуществующую версию стандарта SQL. Это мелочь, поскольку SQL-92 начального уровня очень похож на Core SQL: 1999. Давайте сравним каждую СУБД с Core SQL: 1999.

SQL: 1999 имеет два набора функций: основные функции и дополнительные функции. Нет никаких «уровней», как в SQL-92. Стандартизацию СУБД можно рассматривать с точки зрения ее функций, начиная с основных функций, которые она должна поддерживать, и заканчивая поддерживаемыми неосновными функциями.Это легко сделать, потому что у функций есть идентификаторы и имена. Например, если СУБД правильно обрабатывает роли, поставщик может заявить о поддержке «основных ролей функции T331» (которая не является основной).

Примечания к функциям

Я опишу каждую стандартную функцию для IBM DB2 UDB Universal Server 7.2, Microsoft SQL Server 2000 и Oracle9i с помощью следующего шаблона:

• Feature-ID не имеет значения, если вы не хотите ссылаться на стандарт ANSI / ISO.Feature-Name — это неофициальный короткий дескриптор, например «Роли» или «Триггеры» — я ожидаю, что большинство читателей знают, что это такое, поэтому дескрипторы очень короткие.

• Прочерк (-) в столбце IBM означает, что СУБД не поддерживает эту функцию.

Одна звездочка (*), как в столбце Microsoft, означает, что СУБД поддерживает функцию, но не синтаксис; то есть Microsoft разрешает создание роли с помощью:

• EXEC sp_addrole ‘rolename’

, но в стандартном SQL синтаксис:

Двойная звездочка (**), как в столбце Oracle, означает, что СУБД поддерживает как функцию, так и синтаксис или что-то близкое к нему.

Знаки — или * или ** означают мою интерпретацию документации поставщика и стандарта SQL: 1999, без тестов, без подтверждения. Я проигнорировал многие детали, которые я решил, что они тривиальны, и, конечно, другие могут заключить иначе.

Отметки показывают, насколько портативна функция, и после того, как вы изучите множество функций, вы поймете, что означает «поддержка стандартов ANSI» для поставщиков. Отдельная отметка показывает, является ли СУБД «более стандартной» по отношению к одной функции, но не подвести итоги.Выборка не является статистически достоверной.

Поддержка основных функций

В этом разделе показаны исключительные случаи, когда хотя бы одна СУБД пропускает базовую функцию SQL: 1999. Поскольку основные функции более важны, чем второстепенные, в этом разделе (только) я объясню каждую отметку.

• Для E051: Oracle запрещает « SELECT столбец AS, столбец » и « FROM table AS table » — ему не нравится ключевое слово AS.
• Для E071 UNION: IBM и Microsoft запрещают « a UNION DISTINCT b ».
• Для E071 EXCEPT: Microsoft запрещает любые формы EXCEPT. Oracle допускает эту функциональность, но требует ключевого слова MINUS, а не EXCEPT.
• Для выражений E121: IBM разрешает « ORDER BY a + 5 », но только если « a + 5 » находится в списке выбора.
• Для курсоров E121: Microsoft не поддерживает предложения WITH HOLD в объявлениях курсоров.
• Oracle поддерживает их, но их объем слишком велик, они работают как с ROLLBACK, так и с COMMIT.
• Для E131: Oracle не отличит NULL от пустых строк.
• Для E141: оператор « CREATE TABLE t (column1 INT, PRIMARY KEY (column1)) » неприемлем для СУБД, которые считают, что NOT NULL должно быть явным. В стандарте говорится, что СУБД должна это делать. Этот недостаток встречается часто.
• Для E151: Microsoft запрещает « SET TRANSACTION… READ ONLY ». IBM запрещает все операторы SET TRANSACTION.
• Для F021: IBM и Oracle имеют метаданные, но не могут запрашивать их с такими операторами, как « SELECT * FROM INFORMATION_SCHEMA.ТАБЛИЦЫ ».
• Для F031 ALTER TABLE: Microsoft и Oracle запрещают необязательное ключевое слово COLUMN в « ALTER TABLE… ADD ».
• Для F031 DROP TABLE: Все три СУБД испытывают трудности со стандартным синтаксисом, который должен иметь вид « DROP TABLE имя-таблицы {CASCADE | RESTRICT} ». Есть несколько похожих ситуаций DROP и REVOKE.
• Для F041: Некоторая поддержка существует для «FROM a [INNER] JOIN b ON…», но « FROM a [INNER] JOIN USING… » — другое дело.
• Для F051: Учитывая изобилие вариантов, которые допускают все три СУБД, досадно, что TIMESTAMP ‘1999-01-01 12:34:56’ всегда является незаконным. Некоторые проблемы также существуют с такими функциями, как CURRENT_DATE.
• Для F311: Как минимум, СУБД должна поддерживать CREATE SCHEMA с предложением AUTHORIZATION. Только IBM делает.
• Для F812: указатель сообщает пользователям, когда их операторы SQL являются стандартными SQL. Регистраторы Microsoft и Oracle не могут показать, что соответствует стандарту SQL: 1999.
• Для S011: IBM позволяет « СОЗДАТЬ РАЗЛИЧНЫЙ ТИП аудио как BLOB (1M) ». Функция Microsoft sp_addtype () не предоставляет аналогичных функций.
• Для E21-04 — E21-11: функция Microsoft LEN возвращает обрезанную длину, которую я классифицирую как неподдерживаемую. Все остальные функции char поддерживаются, но их имена различаются. Например, сравните IBM «SUBSTR (x, 1,10)» с SQL: 1999 « SUBSTRING (x FROM 1 FOR 10) ».

Поддержка дополнительных функций

Теперь давайте посмотрим на неосновные функции.Для этой диаграммы я выбрал только функции, поддерживаемые хотя бы одной СУБД — если никто не поддерживает функцию, она неинтересна, какой бы красивой она ни была. Затем я исключил функции, которые, как мне кажется, неинтересны из-за непрактичности. А вот что осталось, вот диаграмма без примечаний.

Oracle поддерживает несколько дополнительных функций, чем IBM или Microsoft.Вам решать, важны ли какие-либо из них.

Поддержка хранимых процедур

Синтаксисы поставщиков в хранимых процедурах отличаются больше, чем в обычном SQL. В качестве иллюстрации вот диаграмма, показывающая, как выглядит CREATE PROCEDURE на трех диалектах. Я использую одну строку для каждой важной части, поэтому вы можете сравнивать диалекты, читая через строку.

Oracle поддерживает несколько дополнительных функций, чем IBM или Microsoft.Вам решать, важны ли какие-либо из них.

Поддержка хранимых процедур

Синтаксисы поставщиков в хранимых процедурах отличаются больше, чем в обычном SQL. В качестве иллюстрации вот диаграмма, показывающая, как выглядит CREATE PROCEDURE на трех диалектах. Я использую одну строку для каждой важной части, поэтому вы можете сравнивать диалекты, читая через строку.

— Данные из настройки производительности SQL ( Gulutzan and Pelzer, Addison-Wesley , 2002)

Столбец «SQL: 1999 / IBM» показывает, что стандартный синтаксис и синтаксис IBM совпадают (единственная небольшая разница состоит в том, что IBM потребует дополнительное предложение LANGUAGE SQL и точку с запятой после слов «END IF», чего у меня нет. показано).Столбец «Microsoft / Sybase» показывает заметно другой синтаксис и игнорирует тот факт, что Microsoft теперь позволяет вам произносить SET вместо SELECT, например « SET @ param1 = 1 .» Столбец «Oracle» показывает еще один синтаксис.

Если Microsoft и Oracle захотят поддержать стандарт, им придется скопировать IBM. На данный момент они предпочитают указывать в других направлениях. Microsoft обещает, что в ее следующей версии будет улучшена поддержка хранимых процедур для C #; Oracle любит делать упор на хранимые процедуры Java.

SQL: 2003 Возможности

Для описания SQL: 2003 мне потребовалась бы целая серия статей. Но я лучше скажу что-нибудь вводное, так как я уверен, что есть читатели, которые еще не слышали об этом. SQL: 2003 — это следующая версия стандарта. Было бы безопаснее назвать это SQL: 200n — большинство людей так и делают — потому что мы все еще не уверены, что Комитет опубликует когда-нибудь в 2003 году. Я рискую, потому что верю в текущее расписание Комитета. Основные особенности SQL: 2003: больше типов коллекционных данных, более четкая объектно-реляционная спецификация и ссылки на новые части, такие как XML.Большой недостающей функцией SQL: 2003 является стандартный тип данных BIT SQL: 1999, но это сбивало с толку, и никто из Большой тройки его все равно не поддерживал. Думаю, по нему будет немного не хватать.

На следующей диаграмме показаны функции SQL: 2003, которые уже реализованы по крайней мере в одной СУБД. Я собираюсь проявить щедрость в своих оценках, потому что некоторые детали синтаксиса будут изменены вплоть до июля 2003 года.

Большинство уже реализованных функций — это скалярные функции или функции набора, представляющие интерес для ограниченного круга пользователей.Ожидайте немного большего волнения, когда каждый поставщик выпустит свою следующую версию.

Скептики

Бывший член Комитета (Джо Селко) заявил в Usenet:
«Серьезно, стандарт SQL-99 никуда не денется».

Другой участник (Майкл Горман) написал критическую статью под названием «Является ли SQL более реальным стандартом?» оправдывая этот прогноз:

«Конкуренция [между поставщиками СУБД] упадет, цены вырастут, а переносимость программ, данных и обученного персонала прекратится.”

Основная критика — при условии, что я никого не искажаю — заключается в том, что нет никаких средств обеспечения соблюдения стандартов, которые могли бы гарантировать, что поставщики действительно следуют стандарту. Без принуждения происходит расщепление, как это было в Unix. И поставщику слишком легко воспользоваться преимуществами стандарта, заявив о его соответствии, но на самом деле не предоставив его. (Я знаю одного поставщика, который делает это, но я не буду называть имен, потому что
я считаю, что претензия вызвана недоразумением.)

С другой стороны, прогресс действительно есть.Вот несколько примеров поставщиков, которые в прошлом не соблюдали требования, но увидели свет.

• IBM с энтузиазмом относится к тому, чтобы сделать «стандартный интерфейс командной строки» своим собственным интерфейсом, и если вы изучите интерфейс, вам будет трудно отличить его от ODBC.
• В течение нескольких лет у Microsoft был продукт, который не мог хранить пустые строки, потому что их можно было спутать с NULL. В Microsoft SQL Server 2000 такой проблемы нет.
• До недавнего времени Oracle настаивала на синтаксисе соединения в предложении WHERE.Но Oracle9i отлично работает с [INNER] JOIN внутри предложения FROM.

Почти все стандартные функции, которые я обсуждал в этой статье, являются новыми. Несколько лет назад ни один поставщик их не поддерживал. Теперь по крайней мере один. Я не утверждаю, что это всегда происходит из-за давления со стороны Комитета — возможно, на стандарт повлиял поставщик, а не наоборот. Но иногда, если гора не достанется Мухаммеду, Мухаммед уйдет на гору.

Написание переносимого кода

Простой совет для переносимого кода: используйте наименьший общий знаменатель.Вот несколько небольших советов:

• Скажите « INSERT INTO », а не просто « INSERT », что является сокращением Microsoft / Sybase.
• Скажите « 10.5E10 » вместо « 10.5e10 ». По какой-то причине буква e в нижнем регистре недопустима в литералах с плавающей запятой SQL: 1999. SQL: 2003 исправит эту оплошность.
• Скажите « DEFAULT 5 NOT NULL » вместо « NOT NULL DEFAULT 5 ». В SQL: 1999 предложение столбца по умолчанию должно предшествовать предложениям ограничений.
• Избегайте использования имен, которые могут быть зарезервированы ключевыми словами в каком-либо другом диалекте. Общая рекомендация — использовать идентификаторы с разделителями (идентификаторы в кавычках), но идентификаторы с разделителями должны быть чувствительны к регистру. Так что просто добавьте символ подчеркивания в конце имени. Ни одно зарезервированное ключевое слово никогда не заканчивается на _. Например:

CREATE TABLE Element… / * плохо, SQL: зарезервированное слово 2003 * /

CREATE TABLE «Element»… / * лучше, но возможно
CREATE TABLE Element_… / * better * /

И когда вы используете новую функцию, примите во внимание, является ли она стандартной и поддерживают ли ее несколько СУБД.Мои графики помогут.

Список литературы

Майкл Горман, «Является ли SQL более реальным стандартом?», Www.tdan.com/i016hy01.

No related posts.