Существует ли «стандартный SQL»?

Можно ли гарантировано выделить множество стандарта SQL 92, которое будет везде работать одинаково?

select a from b where c везде работает одинаково. Но тебе это ничего не даст - различное управление транзакциями и сессиями не дадут тебе работать(+ всё это конфигурируется, т. е. сервер по-разному может быть настроен). Недообёртки типа jdbc, унифицирующие только вызовы нативной клиентской либы, так же не помогут.

Без специализации ты всё равно не обойдёшься. Стандарт sql слишком убог. Либо бери ОРМ нормальную - по идее, там как раз поверх любой поддерживаемой базы можно работать.

Сейчас вроде бы везде принято через обёртки работать. На каком языке/фреймворке проект?

Ну, тогда я просто JPA Hibernate возьму.

Ну и для интереса - как оно на нижнем уровне работает.

Use timestamp

Или без ORM не обойтись?

А что легче? Подключить драйвер или все запросы перелапывать?

ИМХО, я пробовал оба подхода, ORM веселее.

А юзкейс какой?

Зачастую для перфоманса приходится хардкодить костыли для выбора более-менее ок плана. Они не кроссплатформенны по определению.

Ну и для интереса - как оно на нижнем уровне работает.

Вводится абстракция диалкет которая содержит СУБД-специфичные вещи.

что в MySQL автоинкремент

Я думал, автоинкремент только в MySQL есть.
По вопросу:
Есть SQL 92
ORM, вообще-то, используют в ОО языках для мапа SQL данных на модели. Если вы используете ORM для другого, у меня для Вас плохие новости.

Спасибо комитету ANSI, который отличился целой чередой неюзабельных стандартов. По сути, написав свои запросы на ANSI SQL. ты написал их для IBM DB2. И они непортируемы, потому что в ANSI, например, не существует изоляции snapshot. А в первом стандарте не было джоинов и изоляция была только serializable.

без ORM не обойтись?

А при чем тут ORM? Построители запросов работают без ORM.

Либо бери ОРМ нормальную - по идее, там как раз поверх любой поддерживаемой базы можно работать.

И как ОРМ позволит обойти тот факт, что в Oracle пустая строка эквивалентно NULL, а в MySQL это разные вещи?

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

А юзкейс какой?

В последствии обойтись минимальными изменениями raw SQL, если вдруг в проекте сменится СУБД.

Если вы используете ORM для другого, у меня для Вас плохие новости.

Имелся в виду JPA Hibernate Query Language (HQL)

И как ОРМ позволит обойти тот факт, что в Oracle пустая строка эквивалентно NULL, а в MySQL это разные вещи?

Рассматривать это как UB и не сравнивать их, очевидно же. :)

У меня был (и сейчас потихоньку поддерживается) проект с переключением между SQLite (локальный вариант) и PostgreSQL (клиент-серверный). Но клиент толстый, логика крутится на клиенте, БД отвечает именно за данные.

Клиент-серверный вариант появился первым, и изначально многое было сделано на хранимых процедурах (PL/pgSQL). При появлении локального варианта для них пришлось написать плюсовые аналоги и пускать их на клиенте. Кое-что пришлось подпиливать, например скобки из SELECT DISTINCT убирать.

В последствии обойтись минимальными изменениями raw SQL, если вдруг в проекте сменится СУБД.

«Вдруг», скорее всего, не получится, придётся тщательно тестировать на новой СУБД всю логику. И кое-где, вероятно, костылить. В общем, жить можно, но осторожно.

Можно ли гарантировано выделить множество стандарта SQL 92

И этим все сказано …

Существует ли «стандартный SQL»?

Скорее общий подход к разработке DSL для СУБД.
А так - где-то, что-то будет идентично.
Использование лишь SQL как правило пригодно лишь для части задач.
Поэтому к каждой СУБД «прикладывается» процедурный язык.
А в разных СУБД они также схожи как

Иван и ВанЧжанПинь

Владимир 123

чтобы написанное работало с большинством СУБД без переделок

А зачем? Чаще ЯП проекта меняют, чем СУБД. К тому же портировать код с одного SQL на другой не так уж и сложно. А вот чтобы ORM поменять придется всё напрочь переписывать. Так что привязка к ORM гораздо хуже привязки к диалекту SQL.

Поэтому к каждой СУБД «прикладывается» процедурный язык.

А вот в этой области в основном встречаются лишь «велосипеды», а «лимузинов» - НЕТ.

Владимир 123

А вот в этой области в основном встречаются лишь «велосипеды», а «лимузинов» - НЕТ.

1С, правда разработала интересный язык запросов.
Да еще сделала визуальную обвязку к нему - СКД.
Да мало того, предоставила возможность пользователям «круто» настраивать отчеты.
Но ИМХО такие пользователи лишь гики, а бухгалтерам нужна лишь одна кнопка

Сделать ВСЕ!

Владимир 123

Ныне МЕГА тред появился ЯОС - 2020-02.
Из пустое в порожнее обсуждают, да еще ОДНОБОКО /Россию чехвостят/.
А ведь нынешнее политика и взаимоотношение государств похоже на

Стаю у которой есть ВОЖАК

Владимир 123

В последствии обойтись минимальными изменениями raw SQL, если вдруг в проекте сменится СУБД.

Нереально совсем в проектах сложнее hello world. Если очень хочется другую СУБД — можно использовать несколько одновременно (при условии что данные не пересекаются и не нужно распределённых транзакций).

Стандарт sql слишком убог

наоборот
он настолько крут, что ни одна существующая БД не поддерживает все его фичи в полном объёме

Тут нужно еще напомнить (может всякие сишники не вкурсе), что в SQL трехзначная логика. Таким образом, запрос

select * from foo where bar=:baz

при переданном :baz == '' в случае оракла в результате ничего не выберет а MySQL выберет записи с пустой строкой bar

Чтобы в оракле выбрать тоже самое нужно переписать запрос на

select * from foo where bar is null

В общем, особенности конкретных диалектов SQL приводит к тому, что при миграции на другую СУБД, всё равно надо перепроверять все запросы. ОРМ тут не панацея.

В общем, особенности конкретных диалектов SQL приводит к тому, что при миграции на другую СУБД, всё равно надо перепроверять все запросы.

Ну собсно, я про это и писал.

И как ОРМ позволит обойти тот факт

Понятия не имею, ОРМ не использую. А в чём твоя проблема? На вручную набиваемых запросах ты это обойти можешь? Вот и нормальная ОРМ так же обойдёт. Если не можешь - ты ламерок и никакие факты тебе не нужны.

Назови и покажи эти фичи.

в ANSI, например, не существует изоляции snapshot

Где окромя убогих блокировочников оно есть?

А в первом стандарте не было джоинов и изоляция была только serializable

А ещё раньше и всего остального не было.

Где окромя убогих блокировочников оно есть?

Вообще-то на всех MVCC, то есть, кроме блокировочников.

А в первом стандарте не было джоинов и изоляция была только serializable

А ещё раньше и всего остального не было

Ответ неправильный. Первой реляционный MVCC СУБД был Oracle (1979). SQL же произошел из R system, которая 1973. А первый стандарт выпущен в 1986. То есть, стандарт делался уже по факту. Потому он и жив — стандарты, рожденные изначально в комитетах, как правило сдыхали почти сразу после выпуска.

Вообще-то на всех MVCC

Вообще-то ни на оракле, ни на постгресе этого нет.

Ответ неправильный

Я знаю, что ты любитель сам с собой разговаривать, поэтому поток сознания даже комментировать не буду. Беги за isolation level snapshot на версионниках.

Если у тебя запросы сильно сложнее, чем crud, то с орм ты обделаешься. Смотри в сторону jooq, mybatis, jdbi, jdbc templates. Хибер типа работает со всем, да, но как и через что оно работает - это вопрос отдельный. Орм-джуны с курсов вещают, что адские провалы в производительности надо заваливать железом, чо как нищеброды и всё такое.

В последствии обойтись минимальными изменениями raw SQL, если вдруг в проекте сменится СУБД.

Тут или забить хер, потому что СУБД не меняется вдруг, или как вайтишник избегать raw sql под страхом кары.

Имелся в виду JPA Hibernate Query Language (HQL)

Он не имеет к нативному sql никакого отношения.

Ключевая проблема ORM - ООП не натягивается на скалярную природу данных, но натягивается на мозги ООП-нутых программистов. Используя ORM, hibernate etc. твой код будет работать на любой бд одинаково медлено.

Спаси планету от истощения U235 не заставляя сервер жрать больше электричество - не используй bar is null - ведь индексы по полям с null не работают.

А в чём твоя проблема? На вручную набиваемых запросах ты это обойти можешь? Вот и нормальная ОРМ так же обойдёт.

У меня-то нет проблем, а вот ты давеча советовал:

Либо бери ОРМ нормальную - по идее, там как раз поверх любой поддерживаемой базы можно работать.

Что обоснованное встретило возражение на веру во всемогущий ОРМ.

Если не можешь - ты ламерок и никакие факты тебе не нужны.

Что-то как-то по детски.

Спаси планету от истощения U235 не заставляя сервер жрать больше электричество - не используй bar is null - ведь индексы по полям с null не работают.

Может для тебя будет откровением, но если в резалтсете больше, чем 10% от количества строк в таблице, то использование индекса неэффективно.

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

Твое откровение ''==null в Оракле гораздо более откровение.

EEE владеют не только майки. На сиквел 100% есть стандарт, то ли от ansi то ли от ISO, но, что бы сделать что-то круче hello world нужно пользоваться расширениями конкретной СУБД. Я довольно далёк от темы, но от более погружённых товарищей слышал, что даже JOIN чуть ли не разные в одной ситуации стоит использовать в зависимости от БД.

Пока не будет SQL консорциум, по аналогии с w3c и прочими - так и будет. Но даже и подобные организации не могут полностью устранить эту проблему, т.к. корни её растут ещё и в том, что реализации меняются в связи с требованиями бизнеса, а язык для оперирования ими - не особо.

Два банана этой обезьянке.

У меня-то нет проблем

Есть. Ты начал про «как поможет», но не смог показать хоть что-то конкретное окромя своей иллитности. Ламерков на форумах сразу видно.

Ты хотя бы выдал что-то посерьёзнее, там, нужный тип индекса есть только в одной базе, или про различия в управлении транзакциями и явными блокировками. Отсутствие у тебя представления как можно обобщить '' is null выдаёт ламерюгу.

Что-то как-то по детски

Ага.

Хе хе. Почитай доки чтоли.

Отсутствие у тебя представления как можно обобщить '' is null выдаёт ламерюгу.

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

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

И ты предложил ОРМ в качестве решения, чем ввел ТС в заблуждение. Так что обгадился это ты.

Что же ты тупая такая, маня. Давай я тебе проще объясню.

Я предложил рабочее решение. Ты начал ныть про «как поможет». Далее я тебе сказал как. После ты поломался и начал нести шизофрению «я обосновал» и «никто не озабочен переходом», но ни того, ни другого в треде не наблюдалось.

Поэтому, ламерюга, берёшь и обосновываешь каждый свой высер. Показываешь, где и что ты обосновал и с какого хера ты высрала «никто не озабочен переходом», когда тема об этом. Оправдываться.