metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2013-04-03 01:06 am

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

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

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

[identity profile] fraks-nsk.livejournal.com 2013-04-04 02:55 am (UTC)(link)
Пример запроса выдающего журнал документов, с фильтрами.
Запрос определяет сущность формы.
Кроме этого запроса на форме есть еще один, для режима поиска конкретного документа по параметрам.
Поля те же самые но условия задаются по другому. Можно было вструмить те условия и в этот запрос но тогда пострадала бы читаемость запроса.

-- 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
develop7: (dero)

[personal profile] develop7 2013-04-04 09:19 am (UTC)(link)
Как бы это ещё развидеть.

[identity profile] berezovsky.livejournal.com 2013-04-04 09:21 am (UTC)(link)
Тебя смущает слово gorod?
develop7: (dero)

[personal profile] develop7 2013-04-04 12:42 pm (UTC)(link)
захардкоденные "возврат" и "перемещение", явно прописанные цвета и т.д.

[identity profile] fraks-nsk.livejournal.com 2013-04-05 01:18 am (UTC)(link)
ага, а если делать "правильно" - то все вынести в настройки, получится гигантский лист настроек, юзера в нем нарукоблудят и на разных рабочих местах одно и то же будет разным цветом раскрашено. Спасибо, не надо.
develop7: (Default)

[personal profile] develop7 2013-04-07 05:48 pm (UTC)(link)
откуда эти бинарные метания из крайности в крайность, а?

[identity profile] fraks-nsk.livejournal.com 2013-04-08 01:12 am (UTC)(link)
Потому как бесит уже ваша другая крайность - "писать как положено" и пофиг на необходимость и что это раздувание и усложнение кода.

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

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

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