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

[metaclass]

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

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

Comments

[norguhtar.livejournal.com]

Т.е. ОРМ тянет объекты на клиента, а если у объекта много больших полей которые нужны раз в год - тут с
ОРМ будет сильное падение эффективности.

Вы сами поняли что сказали? На чем будет падение эффективности? На выборке или передаче данных по сети?


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

Вы не поверите, но ОRM такое позволяет без всяких проблем. И да если уж внезапно у меня есть толстый объект я могу указать ORM как дернуть в этом случае. И объем кода с ORM и без ORM в этом случае будет сравним. Вы бы сначала посмотрели что такое ORM более детально и как он работает, а уже потом что-то про него говорили.

[fraks-nsk.livejournal.com]

Я смотрел SQLAlchemy и мнение об ОРМ сформировалось на этой основе.
Потом для Delphi сделали аналогичную фигню, был на форуме фанат этой штуки, типа программу накидать за пару дней можно. Но потом он столкнулся с минусами - с поддержкой, модифицированием формы объектов в базе и необходимости синхронизации изменений в ОРМ - и энтузазизм его угас, вроде даже до нуля, ибо тему ту больше никто не поднимал да и упоминания того продукта я не слышал больше. Хотя он от Борланд/Эмбаркалеро был, а не левый.

[norguhtar.livejournal.com]

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

С указанными минусами вы и со своим велосипедом столкнетесь. И да SQLAlchemy не самый худший вариант, но конечно JPA и ORM который есть в yii все же лучше. Фишка в том что ORM ни в коем случае не надо тащить самому, иначе эта овчинка не стоит выделки. Разрабатывать и сопровождать ORM должны отдельные люди.

[fraks-nsk.livejournal.com]

>> С указанными минусами вы и со своим велосипедом столкнетесь.

Не столкнусь. У меня не ОРМ, я не работаю с объектами в программе. Все объекты только в базе, на клиенте только нужные в конкретном объеме выборки которые не претендуют на полноту данных об объекте но показывают те поля которые именно здесь нужны.

[norguhtar.livejournal.com]

Не столкнусь. У меня не ОРМ, я не работаю с объектами в программе.

Я вам указал почему это ORM. Вы можете сколько угодно упорствовать что это не ORM, но по факту это ORM.

[fraks-nsk.livejournal.com]

Дело не в тянуть ОРМ а в том что я вообще в нем смысла не вижу. Некие его мифические достоинства требуют больших жертв.

[norguhtar.livejournal.com]

Учитывая вашу боязнь нового, вы и не увидите. На этом надо сделать проект с mvc к примеру, а у вас там дельфи во все поля. Которая по технологиям от текущих средств разработки отстает на десятилетие.

[metaclass.livejournal.com]

Схера ли оно отстает. Берем кложурь, генерируем дельфи.
У меня MVC в десктопной опердени на дельфях во всех поля :)

[norguhtar.livejournal.com]

Толсто :)

[fraks-nsk.livejournal.com]

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

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

[norguhtar.livejournal.com]

Да мне пофигу что там от чего отстает.

Это заметно.


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

Я рад за вас. Просто сейчас есть средства позволяющие вести разработку быстрее и удобнее. И отказываться от них право не стоит.

[fraks-nsk.livejournal.com]

На свете много чего есть. С какой стати я должен тратить свое время на освоение технологии которая может быть в чем-то удобнее, но требует кучу времени на изучение и переписывание. Вообще, желание "переписать все заново" нифига не конструктивно. Кроме того у меня проблемы с "быстрее/медленнее" нету. Она не в этом месте.

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

[norguhtar.livejournal.com]

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

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


Вообще, желание "переписать все заново" нифига не конструктивно. Кроме того у меня проблемы с "быстрее/медленнее" нету. Она не в этом месте.

А я где-то говорил про переписать заново? Просто если вы изучили одну технологию и успокоились, то вы можете оказаться в ситуации тех самых товарищей с Cobol.


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

Да не я не против. Чем больше таких людей как вы тем больше ценнее те кто знает более одной технологии и изучает новые.

[fraks-nsk.livejournal.com]

У меня всего один большой проект который будет вечно ;)
Если вдруг он перестанет быть актуальным - у меня есть куча другой работы. Программизм - не единственное мое занятие.

Я в жизни изучил не одну технологию, многие из них уже устарели, например Clipper, FoxPro, Когда-то на фортране писАл, и макроассемблере. Просто сейчас мозг уже не позволяет просто так, из любопытства изучить какую-то новую технологию. Ресурсы ограничены и их становится все меньше.
FoxPro кстати был вполне неплохим инструментом для своего времени, позволял быстро решать задачи. ;) То что я на FoxPro делал за одну ночь между командировками, имея только одну бумажную книжку - справочник и никакого опыта, кроме фортрана и макро, потом на Delphi уже делалось за неделю.
Технологии становятся все сложнее и многочисленнее, каждая заявляется как революция и панацея, но немногие переживают более нескольких лет. Все узнать и изучить невозможно. Да уже тупо и неинтересно.

[norguhtar.livejournal.com]

У меня всего один большой проект который будет вечно ;)
Если вдруг он перестанет быть актуальным - у меня есть куча другой работы. Программизм - не единственное мое занятие.

Я сочувствую тем кому вы его пишете. Они никогда не узнают что бывает лучше.


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

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

[fraks-nsk.livejournal.com]

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

[norguhtar.livejournal.com]

Я пишу его себе.

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

[fraks-nsk.livejournal.com]

Задача программы - не блистать кодом и красотой архитектуры а выполнять поставленные задачи и быть достаточно понятной для поддержки и развития. Архитектура должна позволять вносить изменения не скатываясь при этом до набора костылей.

[anonim-legion.livejournal.com]

А я сочувствую тем, кто покупает еду в российских магазинах, учатся в школах, ходят к местным врачам и ездят по дорогам.

Они никогда не узнают, что бывает лучше.

Но, ведь они - жители - сами все это производят и обслуживают. За деньги. Производят говно и потребляют его же. И система находится в относительном равновесии.

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

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

>панацея революция бизнес-процессы буллшит-бинго

Знаете, у торгового дома проблемой является не софт, а поставщики, покупатели и логистика. Кобол здесь как был необходим и достаточен 30 лет назад, так и сейчас подходит.

[theiced.livejournal.com]

зачем сочувствовать рашкиноидам? мудакам мудачья жизнь.

[norguhtar.livejournal.com]

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

Вы в курсе что такое фактор автобуса? Вот тут он наблюдается в полный рост.


Знаете, у торгового дома проблемой является не софт, а поставщики, покупатели и логистика. Кобол здесь как был необходим и достаточен 30 лет назад, так и сейчас подходит.

Знаете обычно говорят, что про сантехников вспоминают когда начинает пахнуть, в IT ровно точно так же. Про него вспомнят когда сломается. И при использовании старых технологий можно получить адовые убытки. За счет того что придется очень долго искать спецов по технологии и они захотят много денег. Вы не читали вот этот прекрасный образчик http://hrazvedka.ru/guru/obratnyj-promyshlennyj-shpionazh-i-industrialnaya-arxeologiya.html
И это замечу вообще инженерия а не IT.

[prepor.livejournal.com]

вы про это что ли http://www.yiiframework.com/?

[norguhtar.livejournal.com]

Да. Там тоже весьма неплохой ORM

[prepor.livejournal.com]

если допустить что это так и его правда можно сравнивать с алхимией и гибернейтом, что заставляет хороших разработчиков сидеть на пхп? неужели тупо бабки за саппорт хомячков?

[norguhtar.livejournal.com]

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