Какие недостатки вы ощущаете в SQL и какие изменения вы могли бы сделать с этим?

Ответ 1

Лично у меня есть мягкое пятно для баз данных CODASYL, где вы просматриваете наборы данных для доступа к связанным элементам данных... возможно, потому что моим первым опытом работы с базами данных была СУБД DEC. Возможность найти родительскую запись, а затем просто пройти набор детей была проста в использовании; и явные отношения между наборами данных, встроенными в базовую структуру базы данных, - это то, чего, к сожалению, не хватает в реляционных базах данных... и, прежде чем кто-либо подскажет это, внешние ключи являются бледной одномерной тенью этих отношений.

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

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

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

Базы данных OLAP - еще одна отличная альтернатива РСУБД, где данные могут быть легко структурированы как n-мерный куб, где запрос позволяет вам "кусочек и кубик" куба, быстро извлекая сегменты данных. Моим первым введением в OLAP был Oracle Express, который (к сожалению) использует собственный собственный язык запросов, а не стандартный MDX de facto. Однако не все данные могут быть легко установлены на "кубическую" структуру, поэтому они подходят только для определенных типов приложений - хотя практически любые приложения для интеллектуального анализа данных хорошо подходят.

Ответ 2

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

• Дублирующие строки (многоуровневая, а не модель на основе набора)

• Нули и три логики значений добавляют сложность, неоднозначность и несогласованные результаты без добавления какой-либо выразительной способности к языку.

• Синтаксис оператора SELECT гораздо более подробный и сложный, чем реляционная алгебра

• Отсутствие поддержки для нескольких присваиваний означает, что поддержка ссылочной целостности и поддержка ограничений в целом сильно ограничены

Два примера более конкретных проблем запроса, которые сложны в SQL:

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

• Отсутствие ключевого наследования означает, что интерфейсы SQL-запросов неизменно возвращают простые двумерные таблицы, что является основным недостатком для запросов запросов поддержки (OLAP), которые по сути являются n-мерными.

Улучшения? Я не верю, что есть какие-то полезные улучшения, которые имели бы смысл, потому что исправление вышеизложенного изменило бы язык настолько радикально, что не было бы особого смысла даже притворяться, что это SQL больше. Лучший способ продвижения вперед, я считаю, заключается в разработке совершенно новых, действительно реляционных языков. Дата и модель Darwen D, являющиеся наиболее очевидным преемником SQL, уже привели к ряду новых реализаций реляционных языков.

Ответ 3

Чтобы добавить к отличным ответам @dportas, для меня большие "упущенные возможности" в SQL - это то, что предлагаемые временные расширения, известные как TSQL2, никогда не попадали в SQL-стандарт. Следовательно, временные базы данных чрезвычайно трудно получить право даже при использовании полного SQL-92, например. множественное присвоение было бы благом, когда, скажем, секвенированное удаление в таблице действительного состояния требует четырех (a INSERT s, два UPDATE s и a DELETE). Когда вы считаете, что большинству поставщиков не хватает поддержки функций SQL-92 (например, ограничения SQL Server DEFERRABLE, Oracle не хватает aubqueries в CHECK ограничениях и т.д.), То почти невозможно достичь без "худшего" типа процедурного кода.

Ответ 4

С точки зрения языка управления данными SQL имеет несколько недостатков:

• Нет стандартного метода SQL для использования регулярных выражений. Ограничения данных часто выражаются в виде регулярных выражений, и наличие стандартного языка регулярных выражений в SQL будет очень полезным. Я знаю, что SQLite позволяет вам добавить свой собственный механизм регулярных выражений, и я уверен, что другие базы данных тоже это делают, но стандартный вариант будет приятным.
• SQL нуждается в императивном языке программирования в SQL, с языковыми конструкциями, такими как переменные и назначение переменных, лексические замыкания и итераторы.
• SQL нуждается в стандартном способе выражения пользовательских функций, которые могут использоваться в запросах.

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

Ответ 5

Фантастические ответы, dportas: -)

Хотя это не так гламурно, что я хочу в стандарте SQL, это алгоритм разрешения конфликтов ограничений INSERT или UPDATE. MySQL и SQLite реализовал это как расширения стандарта SQL.

Эта ИМО должна быть функциональной функциональностью БД, иначе вы будете общаться с такими вещами, как:

IF (record_exists) THEN
    -- update record
ELSE
    -- insert new record

Что кажется тривиальным, но оно

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

Два запроса можно легко заменить одним:

"Insert OR Update Table (field = value) Where ID = @ID"

Чувствует себя гораздо более естественным: -)

Ответ 6

У вас возникли недостатки, ограничения или недостатки при использовании SQL?

Многие: http://c2.com/cgi/wiki?SqlFlaws

Не могли бы вы легко выполнить ту же задачу с помощью другого DML или язык программирования?

Я уверен, что да. Третий манифест описывает, что мы должны использовать вместо SQL: Учебник D

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

Да: Возьмем, например, переименование столбцов в SQL. Скажем, у меня есть таблица с этими столбцами: a, b, c, d, e, f, g, h, я теперь, скажем, я хочу переименовать столбец a в "X". в SQL мне нужно написать:

SELECT a as X,b,c,d,e,f,g,h,i FROM SomeTable

В учебнике D я пишу только:

SomeTable RENAME ( a AS x)

Или позволяет увидеть это наоборот, что эквивалентно этому запросу Tutorial D:

 SomeTable REMOVE (e)

Ну, это (трудно найти отсутствующий "e".. нет?):

SELECT a,b,c,d,f,g,h,i FROM SomeTable

Или просто скажите мне, с каким кодом легче понять намерение разработчика с этим:

SELECT a as X,c,d,e,f,g,h,i, g+h as z from SomeTable

или с этим (это тот же запрос!):

SomeTable RENAME (a AS X) REMOVE (b) ADD (g+h z)

См? SQL является недостатком для ядра! Или просто попробуйте написать select * из вызова хранимой процедуры. В зависимости от базы данных она может не работать

Можете ли вы предложить улучшения, чтобы сделать SQL более мощным и менее сложно?

Многие, замените его чем-то вроде Tutorial D или Dataphor

Какая реализация продукта RDBMS/SQL вы считаете наиболее надежной?

Надежная PseudoRDBMS? Oracle, DB2 и SQLServer. Надежная РСУБД? НЕТ. Возможно, Dataphor или Rel станет первым... все остальные не имеют права называться реляционными

Какие возможности из среды, отличной от SQL, вы хотели бы видеть реализован в SQL?

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

Предположим, что SQL не существует, что бы вы использовали для манипулирования данные?..

Я прочитаю третий манифест и реализую его. Или, возможно, используйте DataLog или Genexus оба дают вы Независимость от пути доступа, Genexus даже дает вам Нормализация по синтезу, вне возможностей SQL.

Или, совсем недавно, запросы ODATA (но, к сожалению, ODATA разделяет некоторые недостатки SQL)