![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
В Советской Белоруссии SQL разжигает айседа
http://theiced.livejournal.com/238346.html
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
Собственно, про кобол я не знаю, на дельфи пишу уже 15 лет и никак избавится от него не могу (слишком много легаси кода), а вот про SQL я с ним не согласен.
Сам по себе SQL очень хорошо подходит для генерации отчетов. Если отчет сводится к фильтрации-сортировке-группировке множеств - идеально. С рекурсивными CTE - еще и деревья можно обрабатывать, не особо включая мозг. Всунув поверх этого минимальных размеров постобработку на какой-нибудь функциональщине, можно сделать почти любой отчет, пришедший в голову свихнувшимся на Excel выпускникам нархоза, работающим в минстате, минфине и МНС.
Но когда доходит до процедурных расширений, API между СУБД и клиентскими приложениями или каких-нибудь вещей, которые забыли вовремя добавить в стандарт - начинается полная, немыслимая жопа.
Например, проклятая тема - генерация автоинкрементных ключей и возвращение значений автоматически заполненных полей. Кто во что горазд - identity, генераторы, sequence, функции (в каждой СУБД названные по разному), returning, заебы на тему "вызывать в той же транзакции и сессии" и прочая и прочая. Про вариации на тему "вернуть поле, которое заполняется автоматически, но не является ключом/identity" лучше даже не думать.
Неудивительно, что люди при первой же возможности сбегают в ORM (которые являются уже второй производной от всего этого маразма и несут на себе его неизгладимый след).
no subject
У меня нет такого вопроса, формы уже все сделаны и в большом количестве не добавляются.
Мой проект имеет меньше прокладок, он проще, поэтому проще в поддержке и в ознакомлении с ним другим программистом.
Вы меня пытаетесь убедить что без ОРМ я действую неправильно и поэтому мой проект плох.
no subject
Ваш ОРМ решает вопрос как нагенерить 100 форм за 1 день.
У меня нет такого вопроса, формы уже все сделаны и в большом количестве не добавляются.
Используемые мной и остальными в обсуждении этой записи технологии нужны не только для нагенерить 100 форм в день. А еще и для улучшения поддержки кода.
Мой проект имеет меньше прокладок, он проще, поэтому проще в поддержке и в ознакомлении с ним другим программистом.
Ваш проект имеет свои велосипедные прокладки. И это не проще это сложнее. и это хуже. Так-как программисту вместо ага тут используется это надо изучать чего вы там наделали.
Вы меня пытаетесь убедить что без ОРМ я действую неправильно и поэтому мой проект плох.
Я пытаюсь вас убедить что создание своего велосипеда, при наличии готового инструмента это плохо. И ваш проект плох, потому что он написан на устаревших технологиях и сопровождать после вас это никто не будет. Даже не мечтайте.
no subject
>> И это не проще это сложнее. и это хуже.
>> Так-как программисту вместо ага тут используется это надо изучать чего вы там наделали.
Мои прокладки написаны в минималистичном стиле, делают только то что надо мне, их изучить по исходникам гораздо проще чем ваши ОРМ и прочие фреймворки. Остальной код кроме моих прокладок выглядит как из букваря - тут кроме паскаля и прикладной задачи ничего знать и не потребуется.
Мои велосипеды создавались когда вашего супермейнстрима еще не существовало.
По поводу сопровождения после меня - думаю что это просто не потребуется.
Книжный рынок схлопывается и идет переход от сложного торгового бизнеса на арендный где задачи стоящие перед софтом гораздо проще.
"Универсальный решатель всего" и "вечно живущая программа" - это бессмысленные утопии. Все имеет свой цикл жизни, программы в том числе.
no subject
Мои прокладки написаны в минималистичном стиле, делают только то что надо мне, их изучить по исходникам гораздо проще чем ваши ОРМ и прочие фреймворки.
Не проще. У вас нет документации. Никто в здравом смысле сейчас не изучает фреймворки и ОРМ по исходникам. А уж с ORM и framework это сделать проще из-за наличия документации и описания общей идеологии. И что еще лучше я могу найти программиста с опытом работы и с нужным мне ORM и с фреймворком и мне надо будет ему рассказать только особенности нашего ПО, а не наших инструментов. Да и в случае если человек их не знает, но толков, я могу его отправить в документацию по ORM и фреймворку и не тратить на это свое время.
Остальной код кроме моих прокладок выглядит как из букваря - тут кроме паскаля и прикладной задачи ничего знать и не потребуется.
Конечно конечно.
Мои велосипеды создавались когда вашего супермейнстрима еще не существовало.
Это какого же года ваши велосипеды? Первая стабильная версия Spring Framework вышла в 2004 году. Про JEE я уже вообще молчу первая редакция 1999 год.
По поводу сопровождения после меня - думаю что это просто не потребуется.
Все верно. Его просто выкинут.
"Универсальный решатель всего" и "вечно живущая программа" - это бессмысленные утопии. Все имеет свой цикл жизни, программы в том числе.
Про вечно живущие программы речи не идет. Речь идет о соответствии реалиям.
no subject
Не знаю, мне в исходники чужого жабокода приходится лазить регулярно.
J2EE использовать в мелких проектах, поддерживаемых одной конторой - смысла никакого нет. Впрочем, его вообще нет смысла использовать, это дрочево на паттерны и хымыль.
Тут такое дело, что лучше взять адекватный язык и использовать его ORM (http://slick.typesafe.com/), потому что там кода просто на порядок меньше. Язык не требует стоять на голове, чтобы сделать что-либо.
no subject
Не знаю, мне в исходники чужого жабокода приходится лазить регулярно.
Я лазил один раз, мне требовалось понять как делать свои view.
J2EE использовать в мелких проектах, поддерживаемых одной конторой - смысла никакого нет. Впрочем, его вообще нет смысла использовать, это дрочево на паттерны и хымыль.
Новый уже можно, там такого пиздеца с xml не наблюдается уже. Ну или Play! иди Spring Framework. Это дело вкуса. Можно вообще прости господи php если что мелкое надо.
Ну а на другие языки я поглядываю периодически, что в болоте с java не сидеть :]