В Советской Белоруссии 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проектировать свой "язык запросов", сделает никому не нужное говно.

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

[theiced.livejournal.com]

соси хуй убогое.

программисты проектирующие яп для программистов - кложа - явный вин.

[gds.livejournal.com]

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

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

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

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

[fraks-nsk.livejournal.com]

Есть - Firebird. Returning там уже сделали, а генераторы и sequence в нем - одно и то же, просто разный синтаксис для доступа к одному и тому же, типа generator - это для обратной совместимости а sequence - штоп усе по стандарту было, ну и вероятно для перебежавших ораклоидов что бы привычно было.

[metaclass.livejournal.com]

В постгресе есть returning? а зачем тогда currval('...')?

[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 компактен и эффективен, не спорю. Но читать на нём чужой код - избави Ктулху.

[theiced.livejournal.com]

я? перл? это какие такие очевидцы такое рассказали. перл кстати лингвист для уебланов - тоже хороший пример фэйла.

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[bydl0coder.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]

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

[metaclass.livejournal.com]

В mysql их не наблюдается, в mssql они появились только в 2012 версии, возвращение последнего значения - кто во что горазд.

[vit-r.livejournal.com]

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

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

[theiced.livejournal.com]

невсегда возможно ;]

[guamoka.livejournal.com]

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

А подготавливаются они в DWH (помимо всего прочего) не тем же SQL?

[norian.livejournal.com]

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

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

[asvil (from livejournal.com)]

Несколько клиентов обычно.

[theiced.livejournal.com]

гагага

[guamoka.livejournal.com]

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

[veter-r-r.livejournal.com]

Это не Oracle-way. Oracle в таких случаях предлагает купить дополнительную тулзу, отдельный сервер и нанять еще одного администратора.

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

[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?

[metaclass.livejournal.com]

Отчетность, которая плохо сводится к реляционным таблицам.
Тут такое дело - промежуточные данные для отчетности идеально делаются sql запросами. Неважно, в 10 строк или в 100 - ключевой момент, что в схеме БД не создаются новые объекты для таких запросов (их очень неудобно поддерживать).
Но постобработка - лучше это делать на clojure. Например, когда надо 150 кодов аналитики разложить по нетривиальным правилам в 30 пунктов итогового отчета. Я раньше это делал на императивных расширениях SQL - поддержка задалбывает (отладки нет, проверка ошибок через задницу, контроль версий аналогично).
Далее - удобнее завернуть это дело в json на clojure и отдать клиенту (десктопному приложению и js-клиенту) чем отдавать нативным протоколом СУБД клиентской либе этой же СУБД.

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

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

[permea-kra.livejournal.com]

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

[metaclass.livejournal.com]

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