metaclass: (Default)
И таки несамочевидное решение "сделать одноразовую опердень по-человечески, с кодогенератором, F# и тестершами" показало свою полезность и адекватность в первый же день использования оной опердени.
Пользователи по результатам уточнили требования, а внутреннее тестирование обнаружило небольшой баг, что привело к необходимости добавить одно поле в таблицу. Если бы не кодогенерация - я бы сейчас искал и менял вручную с десяток мест, где нужно добавить это поле - объект данных, его дампы, dao-классы, sql-запросы, гриды для отображения, подписи к этим гридам и прочая, и прочая.
А так доработка даже с учетом того, что кодогенератор пока не умеет миграцию БД ни в каком виде, заняла 40 минут.
metaclass: (Default)
Тут у нас вышел указ №420, насчет земельного налога. Там, в основном, меняются ставки налогов и зонирование, но это не самое главное. А самое главное то, что это меняется с первого сентября, т.е. мало того, что в середине года, так еще и в середине квартала.
А у меня опердень уже лет 6 поддерживает работу с декларациями по этому налогу, и там основное разделение - по годам уплаты, т.е. налог годовой.

А сейчас нужно внутри года добавить еще детализацию - "по старому законодательству", "по новому законодательству".
Надо заметить, что поддержку версий законодательства в опердени я не делаю принципиально - т.к. усилий на это требуется непропорционально больше, чем на ручные доработки, учесть всем мыслимые изменения в будущем все равно невозможно и вообще чем хуже работает этот проект, тем лучше - его давно пора закрыть и заменить на SAP R/3 (с удорожанием примерно в 100 раз).

Так вот, сейчас работа этой опердени с этим налогом выглядит так: пользователи вводят списки объектов, облагаемых налогом, в информации по объекту указан год уплаты. Каждый год списки дублируются и корректируются. Обычные пользователи могут работать только с текущим годом, пользователи более высокого уровня, в главной бухгалтерии - могут видеть любой год.
Все это реализовано в виде таблицы "список объектов", view "объекты за текущий год", триггеров, не дающих пользователю менять не свои данные и хранимой процедуры "вывести налоговую декларацию в виде пригодном для обработки скриптами генератора отчетов" (там ОЧЕНЬ сложная печатная форма, совершенно неклассическая).

Так вот миграция: создать еще одну таблицу - список документов. Поместить в нее все рабочие года с 2004 по 2010 и добавить 2010 еще раз - для новых данных. В таблицу "списка объектов земельного налога" добавить поле "документ" с внешним ключиком на таблицу документов. Заполнить это поле, исходя из данных поля "рабочий год". Само поле "рабочий год" грохнуть, заменив на join с таблицей документов(документ однозначно определяет год, соответственно мы это дело хотим нормализовать). Во всех view и триггерах нужно заменить проверки исходя из номера рабочего года на проверку типа "текущий рабочий документ". Во всех отчетах добавить параметр "рабочий документ".
В конечном итоге - дублировать данные с документа 2010 года в документ "2010 год по 420 указу".

Основная проблема во всем этом - это то, что нужно будет предварительно грохнуть все зависимости от главной таблицы начиная от листовых к корню (отчетные SP, затем view), затем произвести миграцию таблицы, а затем создать view и sp заново и назначить опять им права доступа. Зависимости не дадут менять таблицу, в частности, грохать поля, а оставлять поля с устаревшим назначением в таблице - это искать себе проблемы на будущее.

И таки что тогда хорошего в бизнес-логике на стороне СУБД?

Вуду^5

Mar. 31st, 2010 05:40 pm
metaclass: (Default)
Генерил кодогенератором опердень, понадобилось добавить способ описания предикатов проверки прав доступа пользователей (типа "этот пользователь видит только данные своего филиала, или же только относящиеся к налоговой инспекции в городе где этот филиал"). Ну отдельные проверки понятно - запрос типа "exists(select 1 from UserDepartments where UserID=current_user and DeptID=OperdenTable_DeptID)" но мне понадобилось их объединять в итоговый предикат отдельно описанными логическими функциями.
Не нашел ничего лучше, как вкрутить первый попавшийся в гугле под руки парсер s-выражений на F#, который был там приведен как пример использования fsyacc и fslex, затем буквально за 5 минут написал конвертор этих выражений в условия для where в sql-запросах.

Т.е., ко всей этой опердени на смеси SQL,F#,дельфи и жутких xml-метаданных еще добавилось и подмножество лиспа :)

Кстати, весь модуль опердени (2 справочника, 4 ведомости, куча проверок, внешних ключей и зависимостей от других модулей)), ради которого это все затевалось, за полдня на оном безумии сделала специально вышедшая из декрета сотрудница.

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

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 19th, 2017 11:35 am
Powered by Dreamwidth Studios