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

Question

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

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

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

Answer 1

1) [ВЛЕВО | ВПРАВО] ПОЛУ ПОСОЕДИНЯЙТЕСЬ и [ВЛЕВО | RIGHT] ANTI JOIN Это позволило бы мне написать что-то вроде

-- return customers who have placed at least one order
SELECT c.*
  FROM Customers c
  LEFT SEMI JOIN o ON o.CustomerId = c.Id

-- return customers who have NOT placed any order
SELECT c.*
  FROM Customers c
  LEFT ANTI JOIN o ON o.CustomerId = c.Id

Это будет иметь точно такой же результат, как и

SELECT c.*
  FROM Customers c
 WHERE c.Id IN(SELECT CustomerId FROM Orders)

и

SELECT c.*
  FROM Customers c
 WHERE c.Id NOT IN(SELECT CustomerId FROM Orders)

соответственно. Однако синтаксис IN (или в значительной степени эквивалентный EXISTS) намного сложнее, чем предлагаемый мной синтаксис, особенно в более сложных случаях.

Конечно, на таблицу semi / anti-join нельзя ссылаться, поэтому это НЕЗАКОННО:

-- Error, can't reference semi joined table.
SELECT c.*, o.OrderNumber
  FROM Customers c
  LEFT SEMI JOIN o ON o.CustomerId = c.Id

2) Было бы неплохо иметь хорошее решение для

WHERE Column IN('a', 'b', 'c')

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

WHERE Column IN(ARRAY @array)

и вызывающий код привязывает @array к массиву.

Редактировать: я только что подумал еще об одном

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

Answer 2

Специфично для SQL Server:

Некоторые приличные функции даты, такие как TRUNC. Улучшения полнотекстового поиска (лучший контроль над логикой сопоставления)

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

Полный синтаксис и проверка ошибок хранимой процедуры при ее компиляции (не только при запуске)

Да, это начинает звучать так: «Мне нужны все функции Oracle в SQL Server без всякой сложности (и стоимости!)»

Answer 3

Команда CreateOrAlter.

Мне надоело переключаться между «Create Proc» и «Alter Proc». Мне все равно, создавать это или изменять, я просто хочу, чтобы конечный результат был тем, что я положил в тело процедуры.

Answer 4

Вложенные агрегатные функции.

PostgreSQL не допускает что-то вроде SELECT MAX (COUNT (*)) ...

Answer 5

Foreing-ключи, управляющие датами интервалов в других таблицах

Например, для таблиц:

TABLE_A(begin DATE, end DATE)
TABLE_B(day DATE)

Какой-то способ определения On TABLE_B:

FOREIGN KEY (day)
  REFERENCES INTERVAL ON TABLE_A (begin, endd)

Answer 6

LINQ-подобные функциональные возможности интеграции с SQL: -)

Answer 7

Вычисляемые столбцы.

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

Answer 8

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

---

РЕДАКТИРОВАТЬ: QBE - это не-SQL методология для запроса реляционных данных. Чтобы добавить его в SQL, может выглядеть что-то вроде

ВЫБРАТЬ столбцы
ОТ стола
ГДЕ ПРИМЕР (имя, фамилия, дата рождения) = ('Фред%', 'Джонс', '20090209')

Функционально для поддержки чего-то похожего на то, что имеет Access для графического конструктора querydef. Вы даете ему список полей и собираете набор подходящих пользовательских входных данных, и оптимизатор отбрасывает не указанные столбцы и оптимизирует остальные.

Answer 9

Мне бы очень хотелось увидеть возможность добавлять предложение WHERE во время создания индекса:

CREATE INDEX BAR ON FOO (FooName, FooId) WHERE FooEnabled = 1;

Затем оптимизатор может использовать это при обработке SQL следующим образом:

SELECT FooId, FooName
FROM Foo
WHERE FooEnabled = 1
ORDER BY FooName;

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

Было бы неплохо иметь синтаксический сахар выше.

Answer 10

Эффективная реализация стандартов SQL, таких как DOMAIN, для тех платформ, которые их не поддерживают.