Которые являются улучшениями SQL, которых Вы ожидаете?

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

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

Массивы

я не уверен, что сдерживает это, но отсутствие вывода массивов для временной работы таблиц и связанной путаницы.

Некоторая таблица UPGRADE, которая позволяет , вносит изменения на таблице, чтобы быть похожей, учитывая :

CREATE OR UPGRADE TABLE 
( 
  a VARCHAR,
  ---
)

Мой список пожеланий (для SQLServer)

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

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

2. Собственное устройство хранения данных UTF-8

3. зеркальное отражение Базы данных больше чем с одним резервным сервером и способностью использовать приближение модели восстановления 'простому', если, конечно, все серверы возросли и фиксации транзакции везде.

4. PCRE в функциях замены

5. Некоторый умный способ снова использовать фрагменты больших запросов SQL, сохраненных условий соответствия, выбирает условия... и т.д. Подобные функциям, но на самом деле реализовал больше как макросы препроцессора.

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

Автоматизированное dba уведомление в случае, где оптимизатор генерирует план, отличающийся, что план это, с которым был протестирован запрос.

, Другими словами, каждый запрос может быть зарегистрирован. В то время план сохраняется. Позже, когда запрос выполняется, если существует изменение в плане, dba получает уведомление, что что-то неожиданное произошло.

Увеличенная временная поддержка БД в SQL-сервере. Интервалы, перекрытия, и т.д.

Увеличенный ПО поддержке в SQL-сервере, включая ЗАДЕРЖКУ, ВЫВОД и TOP.

Абстрактные таблицы и разделение на подклассы

create abstract table person
  (
  id primary key,
   name varchar(50)
  );

create table concretePerson extends person
  (
  birth date,
  death date
  );

create table fictionalCharacter  extends person
  (
  creator int references concretePerson.id      
  );

Строковый Agregation на Группе (В Oracle возможно с этим прием ):

SELECT deptno, string_agg(ename) AS employees
FROM   emp
GROUP BY deptno;

DEPTNO EMPLOYEES
---------- --------------------------------------------------
    10 CLARK,KING,MILLER
    20 SMITH,FORD,ADAMS,SCOTT,JONES
    30 ALLEN,BLAKE,MARTIN,TURNER,JAMES,WARD

Я знаю, что это дико нереалистично, но я желаю, чтобы они сделали бы синтаксис ВСТАВКИ и ОБНОВЛЕНИЯ последовательным. Разговор о бесплатной неортогональности.

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

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

РЕДАКТИРОВАНИЕ: Дата или числа, конечно, то же.

РЕДАКТИРОВАНИЕ 2: кажется, что Oracle имеет что-то для движения, недокументированный предикат ПЕРЕКРЫТИЙ. Больше информации здесь .

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

Больше SQL Server, чем SQL, но лучшая интеграция с Управлением исходным кодом. Предпочтительно SVN, а не VSS.

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

ИЗБРАННЫЙ CUSTOMERID, СУММА (C.ORDERS.LINES.VALUE) ОТ КЛИЕНТА C

модернизация А целой вещи GROUP BY так, чтобы каждое выражение в ИЗБРАННОМ пункте не было повторено в пункте

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

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

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

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

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

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 и сборку в последовательных слоях.

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

Функции More OOP:

• хранимые процедуры и функции пользователя

  CREATE PROCEDURE tablename.spname (параметрические усилители) AS...

названный через

EXECUTE spname
FROM tablename
WHERE conditions
ORDER BY

, который неявно передает курсор или текущую запись на SP. (подобный вставленным и удаленным псевдотаблицам)

• определения таблицы с наследованием

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

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

параметризованный порядок, как в:

select * from tableA order by @columName

Автоматическая денормализация.

, Но я могу мечтать.

Улучшенные сводные таблицы. Я хотел бы сказать, что это для автоматического создания столбцов на основе ключей нашло в данных.

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

Что-то еще: связанная с метаданными функция, которая возвратила бы возможные значения данного столбца, если множество возможных значений является низким. Т.е. если бы столбец имеет внешний ключ к другому столбцу, он возвратил бы существующие значения в упоминаемом столбце. Из того, если бы столбец имеет ограничение CHECK как "нечто ПРОВЕРКИ В (1,2,3)", это возвратилось бы 1,2,3. Это помогло бы создать элементы GUI на основе схемы таблицы: Если бы функция возвратила список двух значений, то программист мог бы решить, что виджет переключателя был бы релевантен - или если функция возвратилась - например, - 10 значений, приложение показало выпадающий виджет вместо этого. И т.д.

UPSERT или СЛИЯНИЕ в PostgreSQL. Это - одна функция, отсутствие которой просто поражает. Пост-ГРЭС имеет все остальное; почему они не могут собраться и реализовать его, даже в ограниченной форме?

Проверочные ограничения с подзапросами, я имею в виду что-то как:

CHECK ( 1 > (SELECT COUNT(*) FROM TABLE WHERE A = COLUMN))

Это весь SQL-сервер MS,/T-SQL конкретный:

1. "Естественные" соединения на основе существующих отношений Внешнего ключа.
2. Легко используют сохраненный результат proc в качестве набора результатов
3. Некоторая другая конструкция цикла, кроме того, в то время как
4. Ограничения на уникальность данных через не Нулевые значения
5. КРОМЕ, В, ВСЕ пункты вместо СОЕДИНЕНИЯ LEFT|RIGHT, ГДЕ x НЕ ПУСТОЙ
6. Связанный со схемой, сохранили proc (для упрощения № 2)
7. Отношения, связанные со схемой представления, и т.д. через несколько баз данных

WITH пункт для других операторов кроме SELECT, это означает для UPDATE и DELETE.

, Например:

WITH table as (
  SELECT ...
)
DELETE from table2 where not exists (SELECT ...)

Что-то, что я называю ССЫЛОЧНЫМ СОЕДИНЕНИЕМ. Это присоединяется к двум таблицам вместе путем неявного использования FOREIGN KEY... ССЫЛОЧНОЕ ограничение между ними.

Оператор DIVIDE алгебры отношений. Я всегда очень не хочу иметь необходимость заново обдумать, как сделать весь элементы таблицы a, которые находятся в весь из данных от таблицы B.

http://www.tc.umn.edu/~hause011/code/SQLexample.txt

Поддержка в SQL, чтобы определить, хотите ли Вы, чтобы Ваш план запросов был оптимизирован для возврата первых строк быстро или всех строк быстро.

Oracle имеет понятие подсказки FIRST_ROWS, но стандартный подход на языке был бы полезен.