В Советской Белоруссии 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 позволяющим юзать сервер БД не как просто помойку записей они подсаживаются на этот самый ОРМ. Т.е. шило на мыло.

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

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

[theiced.livejournal.com]

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

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

[theiced.livejournal.com]

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

[theiced.livejournal.com]

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

[norguhtar.livejournal.com]

Текущая абстракция хуле. Но увы в данный момент ничего лучше РСУБД для общих случаев хранить данные не придумано.

[theiced.livejournal.com]

так хуй с ними с рсубд. сам сикль ГОВНО. ну вон то что М пишет - только в 2008ом году indentity попало в стандарт. а в базах мало того что в каждой свой костыль, так ещё и "стандартный" будет... лет через 5-6.

[norguhtar.livejournal.com]

Это вопрос стандартизации, вон возьмем html. Пока другие чуваки не сказали вы заебали мы сделаем свой стандарт, эти w3c вату катать собирались до 2015 года. А в случае SQL со стандартизацией а так же с лидерами все плохо. Ну нету в РСУБД своего webkit.

[theiced.livejournal.com]

ооо. хтмль же. делалось учёными для учёных. получился пиздец непредставимой величины. взять любой фэйл - там всегда пидорасы для хипстеров. или хипстеры для сотрудников нии гит. обычно с коммитетами, спецификациями на 2000 страниц (или вообще безо всякой документации) и обязательной поддержкой латыни и беларуского, марсианских таймзон и без возможности делать вещи нужные каждый день. а там где всё заебись - делали практикующие программисты чуть более чем всегда.

[sbj-ss.livejournal.com]

Да, с поддержкой латыни, белорусского и тамильского. И с тайм-зонами для суток, в которых не 24 часа. Иначе те же самые пидорасы с хипстерами это введут в ни с чем не совместимой версии максимально ублюдочным способом и сделают стандартом де-факто. В SQL насмотрелись уже.

[fraks-nsk.livejournal.com]

Это ОРМ - тотальное гавно ибо
- собственно данные хранить не умеет
- все равно для адекватной эффективности приходится смотреть на работу с СУБД.

Итого - ОРМ всего-лишь ненужная прокладка.

Утрированно.

[fraks-nsk.livejournal.com]

Ну и где к примеру броузеры работающие на кложури, передающие данные на кложури с кложурных сайтегов? Нету? Потому что нафиг оно никому не нужно, ведь гавно же :)

[fraks-nsk.livejournal.com]

Ровно то же можно сказать про вашу кложурь - технодрочеры которы дрочат на язык. А где продукты на нем, захватившие рынок? Нема? Значит кложурь - никому не нужное гавно.

[vp.livejournal.com]

>Итого - ОРМ всего-лишь ненужная прокладка.

Я как бы не согласен совсем. Эффективность адекватна, если уметь этих кошек готовить. Например, Hibernate генерирует при правильном конфиге именно те запросы, которые бы написал сам.

[darkdrip.livejournal.com]

всё блять. буду писать сайтики на mod_plsql. нахуй эти прокладки нужны?

[norguhtar.livejournal.com]

А какие варианты? Закат солнца в ручную? Нет спасибо, я лучше с ORM поработаю.

[fraks-nsk.livejournal.com]

ОРМ - это закат солнца вручную 1,5-2 раза.

[norguhtar.livejournal.com]

Да ладно? Может поделитесь как надо тогда делать? Мне вот правда интересно.

[fraks-nsk.livejournal.com]

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

[fraks-nsk.livejournal.com]

Делюсь.
Нет никакой панацеи. Ни кложурь, ни ОРМ ни SQL ни чего-бы то ни было.
Есть конкретные решения в конкретных случаях, какие-то инструменты для конкретной задачи подходят лучше, какие-то хуже. Но под каждую подзадачу брать отдельный инструмент - значит разводить зоопарк и повышать требования к разработчику, что созвучно его незаменимости.

[norguhtar.livejournal.com]

Нет никакой панацеи. Ни кложурь, ни ОРМ ни SQL ни чего-бы то ни было.

А я где-то говорил что ORM панацея?


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

Вы конкретное решение предложите ага? Сказали ORM, говно теперь расскажите что и где лучше использовать и почему ORM это больший закат солнца в ручную. А такую пространную хрень и я могу написать.