Xpoint
   [напомнить пароль]

Различия SQL-диалектов

Метки: [без меток]
2006-02-11 01:33:59 [обр] Victor Gr.(0/20)[досье]

Добрый день!

Хочется задать вот какой вопрос. Насколько велики различия между SQL-диалектами у разных СУБД? Например, у MySQL, PostgreSQL, MSSQL, Oracle...? То есть, конечно, понятно, что SQL - это стандарт. Но одинаково ли все СУБД его поддерживают?

Сам я работал только с MySQL. И создавая серьёзный проект (PHP) с прицелом на будущее, хочется на архитектурном уровне предусмотреть возможность работы с другими СУБД. И сейчас решаю, как это лучше сделать. Достаточно ли будет создать функцию-обертку для вызова SQL-запроса или придётся создавать функцию для каждого действия с БД, которая в зависимости от выбранной СУБД будет посылать запросы для СУБД на понятном ей SQL-диалекте?

Буду рад узнать опыт людей, занимавшимся таким, имеющих опыт. Спасибо!

спустя 1 час 42 минуты [обр] Василий Свиридов(0/175)[досье]
Вам проще будет пользоваться готовой библиотекой абстракции, типа Pear::DB.
спустя 11 часов [обр] Кирилл [Kirk] Королев(88/673)[досье]
Различия не столько в диалекте (хотя они есть, и их не так мало), сколько в собственных возможностях той или иной (Р)СУБД.
спустя 8 часов [обр] Victor Gr.(0/20)[досье]

"Различия не столько в диалекте (хотя они есть, и их не так мало)"

Гм, а если строго придерживаться SQL-стандарта, могу я расчитывать на адекватную их работу во всех СУБД?

Да, конечно, придется исключить неподдерживаемые всеми СУБД функциями, вроде триггеров и хранимых процедур.

Собственно, всё, что хочется - это SELECT, UPDATE, REPLACE, INSERT. Довольно простые условия.

Хотя, на этом думается, стоит ли вообще распылять себя на разные БД (тем более, такие, какие вряд ли будут на хостинге - вроде Oracle) и сконцентрироваться на максимальной поддержке и качества кода для одной-двух СУБД?

спустя 3 часа 6 минут [обр] Давид Мзареулян(3/1003)[досье]
Victor Gr.[досье] Почитайте вот это: http://phplens.com/lens/adodb/tips_portable_sql.htm. Весьма познавательный документ.
спустя 12 часов [обр] Кирилл [Kirk] Королев(88/673)[досье]
Давид Мзареулян[досье] ух, какая хорошая ссылка.
спустя 1 день 16 часов [обр] Закиров Руслан(12/343)[досье]
  • В MySQL 4.0 нет поддержки вложенных запросов(отказ от вложенных запросов или ограничение версий)
  • В Pg (в Orcale вроде тоже) нет возможности сортировать по полям не входящим в DISTINCT выборку(вложенные запросы)
  • В Pg отвратительная оптимизация DISTINCT запросов(обходится усложнением логики построения запроса)
  • СУБД по разному сортируют NULLы (ничего не поделать, возможно можно настроить на сервере)
  • В Oracle нет LIMIT, OFFSET(эмуляция через вложенные запросы)
  • По разному интерпретируются начальные и конечные пробелы в [VAR]CHAR полях (приходится приводить к одному виду)
  • В MySQL при обычных настройках обрезается строка при превышении длинны без сообщении о ошибке
  • В MySQL поиск обычно case insensetive, а в Pg нужно для этого использовать LOWER или ILIKE, оба варианта могут замедлить производительность (не помню какой быстрее).
  • В Pg нет возможности использовать альяс в конструкции FROM до его определния.
  • Разный подход к обработке строк: кодировки, валидность, длинна, экранирование...
Это маленький список того, что вспомнилось сходу.
спустя 3 дня [обр] Дмитрий Попов(17/509)[досье]

Василий Свиридов[досье]

Вам проще будет пользоваться готовой библиотекой абстракции, типа Pear::DB.

Я эту фразу с недавних пор считаю в крайней степени не правдой.
Ибо уровнем абстракции придется учиться пользоваться отдельно. Зачастую различия в синтаксисе встречаются там, где их совсем не ждешь. И, хоть и в большинстве ADBL есть инструменты "универсализации", не всегда догадаешся, в каком случае надо что-то искать а в каком не надо.

З.Ы. Для меня совсем недавно стало откровением что в MSSQL'е нет даже примерного аналога offset'а или rownum(). (для мускуля: limit a,b). В результате adodb'шный лимит пришлось юзать да и тот тормозил (что естественно)

спустя 3 дня [обр] Василий Свиридов(0/175)[досье]

Ну, я думаю это понятно, что чем универсальней какая-либо библиотека - тем меньше оптимизаций под performance в ней будет. Т.е. вся абстракция сводится только к простейшим вещам. Если нужно писать более сложные запросы, к примеру с большим количеством JOIN'ов или SubSelect'ов - тогда, имхо, только руками. Если я не прав - поправьте...

p.s.
я всегда, по возможности, стараюсь жёстко зацепиться за платформу, и пользовать её по максимуму. (Правда и софт в основном пишу по заказу, под конкретную платформу)

спустя 8 часов [обр] Давид Мзареулян(3/1003)[досье]
Вообще, правильное решение тут — вынесение всего общения с базой на отдельный уровень модели. Тогда при возможном портировании с SQLLite на Oracle потребуется переписать только этот уровень. Пытаться же писать совместимые SQL-запросы, мне кажется, бесполезно — слишком большой бардак в диалектах.
спустя 5 часов [обр] Закиров Руслан(12/343)[досье]

Давид Мзареулян[досье] Странно звучит фраза, ведь если можно переписать уровень модели под другую базу не трогая остальные уровни, то значит у вас уже есть абстракция от особенностей БД и ничего не мешает сделать динамический выбор между реализациями.

Василий Свиридов[досье] Чем большое количество присоединений и подзапросов отличается от малого? Мне кажется ничем. И система, которая умеет строить одно присоединение, может строить и 10-ть.

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

спустя 1 час 23 минуты [обр] Давид Мзареулян(3/1003)[досье]
Закиров Руслан[досье] Всё правильно, я о том и говорю. Сама проблема, поставленная в треде, не стоит того, чтобы с ней возиться — надо систему правильно разрабатывать.
спустя 8 часов [обр] Закиров Руслан(12/343)[досье]
Давид Мзареулян[досье] Где-то так, так как задача прикладного характера и не является отдельным законченным продуктом, а только инструментом, то разрабатываться и развиваться должна только в рамках конкретных проектов.
спустя 48 минут [обр] Василий Свиридов(0/175)[досье]
Закиров Руслан[досье] Отличается тем, что человек, имхо, сможет намного более эффективно соптимизировать сложный запрос, нежели скрипт. Хотя-бы потому, что человек может при этом учитывать схему базы и он знает, где можно жертвовать производительностью, а где - ну никак нельзя. (Моя аргументация правда начинает уходить от абстракции, так что на этом я закончу. А то оффтоп злостный пойдёт ;) )
Powered by POEM™ Engine Copyright © 2002-2005