В Советской Белоруссии SQL разжигает айседа

[metaclass]

http://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.

Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).

Comments

[maxdz.livejournal.com]

Гы-гы... программисты напроектуруют ЯП, как же... :)

Не умеет, к примеру программист айсед пользоваться SQL - и всё туда же, "язык плохой". А заставь айседа cпроектировать свой "язык запросов", сделает никому не нужное говно.

п.с. но насчёт паскаля и борланда - я с ним согласен :)

[gds.livejournal.com]

> Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая.

для нужной бд -- нужный способ получить. Не sql? Ок, лол.

> Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.

что в оракле, что в постгресике -- returning и всё. А что, есть другие реляционные субд?

[sbj-ss.livejournal.com]

Кобол я мельком видел и вздохнул. "IF THISINPUT IS EQUAL TO 001 ADD 1 TO COUNT001". SQL в меньшей мере потащил то же самое — попытки описать на естественном языке вещи, которым в конструкциях естественного языка просто нет аналогов.
Впрочем, беда "академиков" с SQL не в попытках "придумать язык для менеджеров", а в отсутствии смелости сказать "Б" после того, как сказано "А". Если бы хотя бы были предложены фрагменты синтаксиса, покрывающие всё множество решаемых задач, а не его небольшое подмножество, не было бы сейчас ругани на несовместимость. Там же, где есть потребность, но нет стандарта, каждый пойдёт придумывать, что горазд, (при активной поддержке менеджеров, срочно требующих новые фишки), а опоздавшие стандарты только усугубляют ситуацию. В результате в 2013 году многие кроваво-энтерпрайзные РСУБД тупо не поддерживают полностью SQL'92.
Паскакаль - отдельный разговор. Оторванность логических типов от физических неоднократно крепко напакостила, дав борландовцам возможность ломать совместимость. Достаточно вспомнить невозможность записи в нулевой байт строки в Дельфи (полбеды) и переезд поздних версий RAD Studio на UTF-16 по умолчанию (беда). Второе всем привыкшим, что Byte === Char с точностью до контекста использования, переломало существующий код. И если уж предусматривалось, что возможны изменения, нехрен было делать в языке преобразование Byte <=> Char. C/C++ так не испортишь.
Что до языков, придуманных программистами для программистов, здесь тоже не всё гладко. Простой пример - Perl с его write-only программами и необходимостью запоминать назначение $₪ и $℧. Сам же нагнетатель срача theiced, по рассказам очевидцев, использует его, как Shell Script :) Perl компактен и эффективен, не спорю. Но читать на нём чужой код - избави Ктулху.

[fraks-nsk.livejournal.com]

Я так понимаю что люди сбежавшие на ОРМ обнаруживают что кроме потери нормальной работы с нативным серверным SQL позволяющим юзать сервер БД не как просто помойку записей они подсаживаются на этот самый ОРМ. Т.е. шило на мыло.

[asvil (from livejournal.com)]

А чё там во втором абзаце предполагается кроссбазовость что ли? Я, несмотря на возраст, хочу высказаться о том, что кроссплатформенности не существует. Работаем с конкретной базой, значит дрючим все её фишки: sequence, returning, window functions, arrays, gis и т.п.
Видел я переход с мускуля на халявный оракл: пауки и черви.

Ближайшие, на мой взгляд, решения это метаклассовость: http://common-lisp.net/project/elephant/, http://www.franz.com/products/allegrocache/. Но они завязаны на common lisp, а common lisp это тот ещё зашквар.

P.S. Excel ок.

[falcrum.livejournal.com]

Да нормально уже давно сиквенсы работают - чё они тебя так возбудили? :)

[vit-r.livejournal.com]

Хороший ЯП/DSL/что-там-ещё может получиться исключительно в случае когда он спроектирован реальными программистами для реальных программистов.
Хорошим ЯП/DSL/чем-то-ещё считаем такой инструмент, который нужен программистам чтобы писать программы для программистов.

По сути, SQL - язык элементарных запросов. Все данные для неэлементарных запросов должны быть подготовлены в базе данных в том виде, чтобы они получались элементарными запросами. На этом DWH сейчас и поднимается.

[norian.livejournal.com]

> проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей

дык можно юзать клиентский синглтон для генерации, не ?

[guamoka.livejournal.com]

ИМХО, всякие ораклы- это давно уже PHP от баз данных. Вот тут у нас такие-то запросы педалят? А давайте напишем специально для этого случая отдельную ф-цию или придумаем хинт!

Уебланология

[livejournal.livejournal.com]

User theiced referenced to your post from Уебланология (http://theiced.livejournal.com/238876.html) saying: [...] http://metaclass.livejournal.com/800013.html?thread=17348877&style=mine#t17348877 [...]

[Дмитрий Васильев (from livejournal.com)]

А вы не могли бы привести пример какой-нибудь задачи, которая на clojure решается проще чем на sql + plpgsql?

[Дмитрий Васильев (from livejournal.com)]

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

[permea-kra.livejournal.com]

Ребе, а как вам с точки зрения генерации отчетов xquery? Разумеется, имея в виду отсутствие поддержки в реляционках.