![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Внезапно, типичная миграция БД.
Тут у нас вышел указ №420, насчет земельного налога. Там, в основном, меняются ставки налогов и зонирование, но это не самое главное. А самое главное то, что это меняется с первого сентября, т.е. мало того, что в середине года, так еще и в середине квартала.
А у меня опердень уже лет 6 поддерживает работу с декларациями по этому налогу, и там основное разделение - по годам уплаты, т.е. налог годовой.
А сейчас нужно внутри года добавить еще детализацию - "по старому законодательству", "по новому законодательству".
Надо заметить, что поддержку версий законодательства в опердени я не делаю принципиально - т.к. усилий на это требуется непропорционально больше, чем на ручные доработки, учесть всем мыслимые изменения в будущем все равно невозможно и вообще чем хуже работает этот проект, тем лучше - его давно пора закрыть и заменить на SAP R/3 (с удорожанием примерно в 100 раз).
Так вот, сейчас работа этой опердени с этим налогом выглядит так: пользователи вводят списки объектов, облагаемых налогом, в информации по объекту указан год уплаты. Каждый год списки дублируются и корректируются. Обычные пользователи могут работать только с текущим годом, пользователи более высокого уровня, в главной бухгалтерии - могут видеть любой год.
Все это реализовано в виде таблицы "список объектов", view "объекты за текущий год", триггеров, не дающих пользователю менять не свои данные и хранимой процедуры "вывести налоговую декларацию в виде пригодном для обработки скриптами генератора отчетов" (там ОЧЕНЬ сложная печатная форма, совершенно неклассическая).
Так вот миграция: создать еще одну таблицу - список документов. Поместить в нее все рабочие года с 2004 по 2010 и добавить 2010 еще раз - для новых данных. В таблицу "списка объектов земельного налога" добавить поле "документ" с внешним ключиком на таблицу документов. Заполнить это поле, исходя из данных поля "рабочий год". Само поле "рабочий год" грохнуть, заменив на join с таблицей документов(документ однозначно определяет год, соответственно мы это дело хотим нормализовать). Во всех view и триггерах нужно заменить проверки исходя из номера рабочего года на проверку типа "текущий рабочий документ". Во всех отчетах добавить параметр "рабочий документ".
В конечном итоге - дублировать данные с документа 2010 года в документ "2010 год по 420 указу".
Основная проблема во всем этом - это то, что нужно будет предварительно грохнуть все зависимости от главной таблицы начиная от листовых к корню (отчетные SP, затем view), затем произвести миграцию таблицы, а затем создать view и sp заново и назначить опять им права доступа. Зависимости не дадут менять таблицу, в частности, грохать поля, а оставлять поля с устаревшим назначением в таблице - это искать себе проблемы на будущее.
И таки что тогда хорошего в бизнес-логике на стороне СУБД?
А у меня опердень уже лет 6 поддерживает работу с декларациями по этому налогу, и там основное разделение - по годам уплаты, т.е. налог годовой.
А сейчас нужно внутри года добавить еще детализацию - "по старому законодательству", "по новому законодательству".
Надо заметить, что поддержку версий законодательства в опердени я не делаю принципиально - т.к. усилий на это требуется непропорционально больше, чем на ручные доработки, учесть всем мыслимые изменения в будущем все равно невозможно и вообще чем хуже работает этот проект, тем лучше - его давно пора закрыть и заменить на SAP R/3 (с удорожанием примерно в 100 раз).
Так вот, сейчас работа этой опердени с этим налогом выглядит так: пользователи вводят списки объектов, облагаемых налогом, в информации по объекту указан год уплаты. Каждый год списки дублируются и корректируются. Обычные пользователи могут работать только с текущим годом, пользователи более высокого уровня, в главной бухгалтерии - могут видеть любой год.
Все это реализовано в виде таблицы "список объектов", view "объекты за текущий год", триггеров, не дающих пользователю менять не свои данные и хранимой процедуры "вывести налоговую декларацию в виде пригодном для обработки скриптами генератора отчетов" (там ОЧЕНЬ сложная печатная форма, совершенно неклассическая).
Так вот миграция: создать еще одну таблицу - список документов. Поместить в нее все рабочие года с 2004 по 2010 и добавить 2010 еще раз - для новых данных. В таблицу "списка объектов земельного налога" добавить поле "документ" с внешним ключиком на таблицу документов. Заполнить это поле, исходя из данных поля "рабочий год". Само поле "рабочий год" грохнуть, заменив на join с таблицей документов(документ однозначно определяет год, соответственно мы это дело хотим нормализовать). Во всех view и триггерах нужно заменить проверки исходя из номера рабочего года на проверку типа "текущий рабочий документ". Во всех отчетах добавить параметр "рабочий документ".
В конечном итоге - дублировать данные с документа 2010 года в документ "2010 год по 420 указу".
Основная проблема во всем этом - это то, что нужно будет предварительно грохнуть все зависимости от главной таблицы начиная от листовых к корню (отчетные SP, затем view), затем произвести миграцию таблицы, а затем создать view и sp заново и назначить опять им права доступа. Зависимости не дадут менять таблицу, в частности, грохать поля, а оставлять поля с устаревшим назначением в таблице - это искать себе проблемы на будущее.
И таки что тогда хорошего в бизнес-логике на стороне СУБД?
no subject
или там какой-то язык программирования сильно удобнее для таких дел?
(no subject)
no subject
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)