В Советской Белоруссии 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
Запрос определяет сущность формы.
Кроме этого запроса на форме есть еще один, для режима поиска конкретного документа по параметрам.
Поля те же самые но условия задаются по другому. Можно было вструмить те условия и в этот запрос но тогда пострадала бы читаемость запроса.
-- 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
В данном случае с цветами нет никакого смысла выносить это дело в константы.
Для подсовывания цвета в запрос потребуется доп.код.
Для выяснения почему у нас раскрасилось так а не иначе надо посмотреть на объявление константы, что равнозначно лишней вложенности классов чего я старательно избегаю.
Цветов которые нормально смотрятся, читаются и различаются - пересчитать по пальцам одной руки. Никто никогда цвета менять не будет. Смысла выносить в константы - нет.
Бывают другие случаи когда использование констант позволяет повысить удобство и код реально сокращает или делает его неуникальным что можно переносить тупо копипастой или вынести общую функцию наружу. Такое у меня тоже есть, практически в каждой форме.