Простой SQL против диалектов

Question

Поставщики СУБД используют возможности диалекта SQL для дифференциации своего продукта, в то же время заявляя о поддержке стандартов SQL.'Нуфф сказал по этому поводу.

Есть ли какой-либо пример SQL, который вы закодировали, который не может быть переведен в SQL: 2008 standard SQL?

Чтобы быть конкретным, я говорю о DML (операторе запроса), А НЕ о DDL, синтаксисе хранимых процедур или о чем-либо, что не является чисто SQL-оператором.

Я также говорю о запросах, которые вы бы использовали в производстве, а не для специальных материалов.

Редактировать 13 января

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

Answer 1

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

Можно использовать ANSI SQL по большей части во всех системах баз данных и ожидать получения приемлемых результатов в базе данных без каких-либо существенных проблем с настройкой, таких как отсутствие индексов.Однако в любом нетривиальном приложении, вероятно, существует некоторое требование к коду, которое нелегко выполнить переносимым способом.

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

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

Общим механизмом запроса могло бы быть использование ANSI SQL там, где это возможно;другим возможным подходом было бы использование O / R mapper, который может использовать драйверы для различных платформ баз данных.Этот тип механизма должен быть достаточным для большинства операций с базой данных, но потребует от вас выполнения некоторой специфичной для платформы работы там, где он исчерпает себя.

Возможно, вы сможете использовать хранимые процедуры в качестве уровня абстракции для более сложных операций и закодировать набор специфичных для платформы sprocs для каждой целевой платформы.К sprocs можно было бы получить доступ через что-то вроде ADO.net .

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

Answer 2

Oracle имеет некоторые дополнения, такие как Модель или иерархический запросы, которые очень трудно, если не невозможно, перевести на чистый SQL

Answer 3

Даже когда SQL: 2008 может что-то сделать, иногда синтаксис не тот.Возьмем, к примеру, синтаксис сопоставления РЕГУЛЯРНЫХ выражений, используемый SQL: 2008 LIKE_REGEX против MySQL's REGEXP.

И да, я согласен, это очень раздражает.

Answer 4

Часть проблемы Oracle заключается в том, что она по-прежнему основана на стандарте ANSI SQL 1992.SQL Server соответствует стандарту SQL 1999, поэтому некоторые вещи, которые выглядят как "расширения", на самом деле являются более новыми стандартами.(Я полагаю, что предложение "OVER" является одним из таких.)

Oracle также гораздо более строго относится к размещению подзапросов в SQL.SQL Server гораздо более гибкий и разрешительный в отношении разрешения подзапросов практически в любом месте.

SQL Server имеет рациональный способ выбора "верхней" строки результата:"ВЫБЕРИТЕ ТОП-1 ИЗ ЗАКАЗОВ КЛИЕНТОВ По SALES_TOTAL".В Oracle это становится "ВЫБРАТЬ * ИЗ (ВЫБЕРИТЕ ЗАКАЗ КЛИЕНТОВ ПО SALES_TOTAL), ГДЕ ROW_NUMBER <= 1".

И, конечно, всегда есть печально известный Oracle SELECT (выражение) ИЗ DUAL.

Отредактируйте, чтобы добавить:

Теперь, когда я на работе и могу получить доступ к некоторым из моих примеров, вот хороший из них.Это генерируется LINQ-to-SQL, но это чистый запрос для выбора строк с 41 по 50 из таблицы после сортировки.В нем используется предложение "OVER":

SELECT [t1].[CustomerID], [t1].[CompanyName], [t1].[ContactName], [t1].[ContactTitle], [t1].[Address], [t1].[City], [t1].[Region], [t1].[PostalCode], [t1].[Country], [t1].[Phone], [t1].[Fax]
    FROM (
        SELECT ROW_NUMBER() OVER (ORDER BY [t0].[ContactName]) AS [ROW_NUMBER], [t0].[CustomerID], [t0].[CompanyName], [t0].[ContactName], [t0].[ContactTitle], [t0].[Address], [t0].[City], [t0].[Region], [t0].[PostalCode], [t0].[Country], [t0].[Phone], [t0].[Fax]
        FROM [dbo].[Customers] AS [t0]
        ) AS [t1]
    WHERE [t1].[ROW_NUMBER] BETWEEN 40 + 1 AND 40 + 10
    ORDER BY [t1].[ROW_NUMBER]

Answer 5

Распространенный здесь на SO

• НЕТ (SQL Server)
• НВЛ ('Орабл)
• IFNULL ( ПОЛНОЕ число ) (MySQL, DB2?)
• СЛИВАТЬСЯ (ANSI)

Чтобы точно ответить:

ISNULL может легко выдавать разные результаты при объединении на SQL Server из-за приоритета типов данных, согласно моему ответ / комментарии здесь