![[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
Ну вот я говорю что был добавлен давно - ведь с какой-то целью? А удалив его ту цель поломали.
Была другая выборка.
В IBExpert вместе с планом еще показывается статистика - из каких таблиц сколько записей было прочитано/изменено/удалено, с применением индексов и без них. И если данные похожи на реальные - сразу видно где засада может вырасти.
Фишка в том что иногда вы не можете предсказать какие там данные будут. Только предположить и эти предположения могут быть ошибочны.
no subject
no subject
no subject
Запросов не так много, а те что требуют внимания к плану - так и вообще мало.
Впрочем может быть с ОРМ другая ситуация с запросами, они генерятся ОРМ на каждый чих - тогда действительно охренеешь смотреть.
no subject
А не надо смотреть всех выполняемых. Надо смотреть при написании.
Вот заняться мне больше нечем, как сидеть и смотреть как же я туда положу данные. В 90% случаев это будет одинаково, что чтение, что запись. Особенно при CRUD.
Впрочем может быть с ОРМ другая ситуация с запросами, они генерятся ОРМ на каждый чих - тогда действительно охренеешь смотреть.
Еще раз. Их количество ровно такое же какое будет у вас при ваших формах. Фишка в том что если операция типовая мне не надо туда вообще смотреть и писать запрос. А вам приходится смотреть на каждую форму.
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 не сидеть :]
no subject
Запрос определяет сущность формы.
Кроме этого запроса на форме есть еще один, для режима поиска конкретного документа по параметрам.
Поля те же самые но условия задаются по другому. Можно было вструмить те условия и в этот запрос но тогда пострадала бы читаемость запроса.
-- FrmDocs.QSel
-- Журнал складских документов
--
select
bdok.id as id,
iif (bdok.lck = 1, 'Б', '') as lck,
bdok.sf_d as sf_d,
bdok.sf_n as sf_n,
bdok.io as io,
bdok.ndok as ndok,
bdok.data as data,
bdok.type_ as type_,
bdok.idpost as idpost,
iif(oper < 10 , '', 'возврат' ) as ret,
iif(idpost >= 0 , '', 'перемещение') as mov,
post.name || iif((post.gorod = ''), '', ' (' || post.gorod || ')' )
as post_full_name,
bdok.summ_w_nds as summ_w_nds,
bdok.msg as msg,
--
(select count(*) from logprd where (logprd.id_bdok = bdok.id)) as prn_count, -- сколько раз распечатывался документ
--
iif (bdok.io in ('t', 'f'), 'S', '') as ROW_FONTSTYLE, -- перечеркнем удаленные доки
iif(idpost >= 0 , '', 'BLUE' ) as ROW_COLOR -- выделим перемещения синим шрифтом
from bdok
left join spost post on (post.id = bdok.idpost)
where ((bdok.data >= :data1 ) or (bdok.type_ = 1) or (bdok.reserve = 1))
-- по дате будем фильтровать только закрытые документы. А открытые и резервы - целиком,
-- иначе там набирается куча по жизни незакрытых документов
and (bdok.nsklad = :nsklad)
and (bdok.io = :io )
and (bdok.type_ = :type_ )
and ((post.idagent = :idagent) or (:idagent = -1))
and ((bdok.reserve = :reserve) or (:reserve = -1))
order by
data, idpost
no subject
no subject
no subject
no subject
no subject
no subject
В данном случае с цветами нет никакого смысла выносить это дело в константы.
Для подсовывания цвета в запрос потребуется доп.код.
Для выяснения почему у нас раскрасилось так а не иначе надо посмотреть на объявление константы, что равнозначно лишней вложенности классов чего я старательно избегаю.
Цветов которые нормально смотрятся, читаются и различаются - пересчитать по пальцам одной руки. Никто никогда цвета менять не будет. Смысла выносить в константы - нет.
Бывают другие случаи когда использование констант позволяет повысить удобство и код реально сокращает или делает его неуникальным что можно переносить тупо копипастой или вынести общую функцию наружу. Такое у меня тоже есть, практически в каждой форме.