Какие улучшения SQL вы ждете?

Question

Работа с SQL показывает нам некоторые ограничения и дает нам возможность представить, что может быть.

Каких улучшений в SQL вы ждете? Что бы вы поставили поверх списка желаний?

Думаю, было бы неплохо, если бы вы опубликовали в своем ответе базу данных, в которой отсутствует запрос функции.

Answer 1

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

SELECT * FROM EXEC [master].[dbo].[xp_readerrorlog]

Answer 2

Я знаю, что это дико нереально, но я бы хотел, чтобы они согласовывали синтаксис INSERT и UPDATE. Поговорим о безвозмездной неортогональности.

Answer 3

Оператор для управления диапазоном дат (или чисел):

where interval(date0, date1) intersects interval(date3, date4) 

РЕДАКТИРОВАТЬ: Дата или цифры, конечно, то же самое.

РЕДАКТИРОВАТЬ 2: Кажется, Oracle есть что-то, недокументированный предикат OVERLAPS. Подробнее здесь .

Answer 4

Приличный способ пройтись по дереву с иерархическими данными. Oracle имеет CONNECT BY, но простую и распространенную структуру хранения объекта и самоссылочного соединения обратно в таблицу для «родителя» сложно запросить естественным образом.

Answer 5

Больше SQL Server, чем SQL, но лучшая интеграция с Source Control. Желательно SVN, а не VSS.

Answer 6

Неявные объединения или как они должны называться (то есть предопределенные представления, связанные с определением таблицы)

ВЫБЕРИТЕ CUSTOMERID, СУММУ (C.ORDERS.LINES.VALUE) ИЗ ЗАКАЗЧИК C

Редизайн всего объекта GROUP BY, так что каждое выражение в предложении SELECT не должно повторяться в предложении GROUP BY

Некоторая поддержка выражений let или других более допустимых мест для использования псевдонима, немного связанных с вещью GROUP BY, но я иногда нахожу то, что я просто ненавижу, когда Oracle заставляет меня использовать внешний выбор только для ссылки на большой выражение по псевдониму.

Answer 7

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

Answer 8

Способ динамического указания столбцов / таблиц без необходимости прибегать к полной динамической SQL, которая выполняется в другом контексте.

Answer 9

Возможность определять столбцы на основе других столбцов до бесконечности (включая устранение неоднозначности).

Это надуманный пример, а не реальный случай, но я думаю, вы поймете, куда я иду:

SELECT LTRIM(t1.a) AS [a.new]
    ,REPLICATE(' ', 20 - LEN([a.new])) + [a.new] AS [a.conformed]
    ,LEN([a.conformed]) as [a.length]
FROM t1
INNER JOIN TABLE t2
    ON [a.new] = t2.a
ORDER BY [a.new]

вместо:

SELECT LTRIM(t1.a) AS [a.new]
    ,REPLICATE(' ', 20 - LEN(LTRIM(t1.a))) + LTRIM(t1.a) AS [a.conformed]
    ,LEN(REPLICATE(' ', 20 - LEN(LTRIM(t1.a))) + LTRIM(t1.a)) as [a.length]
FROM t1
INNER JOIN TABLE t2
    ON LTRIM(t1.a) = t2.a
ORDER BY LTRIM(t1.a)

Прямо сейчас, в SQL Server 2005 и более поздних версиях, я бы использовал CTE и создавал последовательные слои.

Answer 10

Я бы хотел, чтобы поставщики действительно стандартизировали свой SQL. Они все виноваты в этом. Предложение LIMIT/OFFSET из MySQL и PostGresql является хорошим решением, которое, похоже, больше никто не делает. У Oracle есть свой собственный синтаксис для явных JOIN s, в то время как все остальные используют ANSI-92. MySQL должен отказаться от функции CONCAT() и использовать ||, как и все остальные. И есть многочисленные пункты и заявления, которые находятся за пределами стандарта и могут быть более широко распространены. MySQL REPLACE является хорошим примером. Это еще не все, что связано с приведением типов и сравнением типов, причуды типов столбцов, последовательности и т. Д.