Внезапно, типичная миграция БД.

[metaclass]

Тут у нас вышел указ №420, насчет земельного налога. Там, в основном, меняются ставки налогов и зонирование, но это не самое главное. А самое главное то, что это меняется с первого сентября, т.е. мало того, что в середине года, так еще и в середине квартала.
А у меня опердень уже лет 6 поддерживает работу с декларациями по этому налогу, и там основное разделение - по годам уплаты, т.е. налог годовой.

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

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

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

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

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

Comments

[kosiakk.livejournal.com]

а чем SAP будет лучше? они сами следят за законодательством?
или там какой-то язык программирования сильно удобнее для таких дел?

[metaclass.livejournal.com]

Дороже в 100 раз. Консультантам платят больше. Работать сложнее.
В общем, серьезная система - всем будет очевидно, что ей нужно уделять внимание и заранее планировать обновления в связи с законодательством.

[miadzviedz.livejournal.com]

Абстрагируясь от проблем ПО и БД, предлагаю руководство (да и весь личный состав) МНС развесить на столбах вдоль МКАДа за вредительство. Больший ущерб экономике, нежели они, могут нанести только стихийные бедствия.

[teewoon.livejournal.com]

Зато 1С-франчайзеры и кастомайзеры имеют вагон работы =)

[sergiej.livejournal.com]

Ребе, вы так привыкли писать дизайн своих решений в ЖЖ, что мне кажется будущим поколениям для поддержки оперденей надо читать ваше ЖЖ а не документацию.

[metaclass.livejournal.com]

Я просто дублирую - в баг-трекер и в ЖЖ.

В ЖЖ подробнее, так как народ не в курсе подробностей :)
Ну и опять же, DBMS-срач было бы полезно.

[sergiej.livejournal.com]

Ну да, а вот была бы это объектная база - унаследовал объект, добавил к наследнику новые поля, свойства и медоды, и всё шололадно :))))0

[metaclass.livejournal.com]

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

[sergiej.livejournal.com]

Ну помогла бы, если бы существовала. А так помогла бы просто гадкая джава, если бы уровень доступа к базе был скрыт под вменяемым объектом. Унаследовал объект, поменял у него таблицу(цы) на которую он мапится, "старые" объекты работают по-старому, новые по-новому. Интерфейс у обоих объектов можно оставить совместимым, если логика позволяет.

[metaclass.livejournal.com]

Да, изоляция за отдельным слоем бы помогла.
Но она сама по себе тянет столько лишних забот, что непонятно что лучше - то ли делать этот слой доступа, то ли по старинке руками пилить :)

[sergiej.livejournal.com]

Само собой, но в больших конторах позволяет отделить толпы обезьян, умеющих только Ctrl + Space в эклипсе, от их группы продвинутых и более дорогих сородичей, умеющих курить базу.

[permea-kra.livejournal.com]

ребе, а вы не щупали xml-dbms?

[metaclass.livejournal.com]

Нет. Это такое же вуду, как пост-реляционные и прочие объектные базы - они теоретически представляют собой тыкву, сделанную из соображений "мы не осилили реляционную модель и вообще академиев не кончали".

[permea-kra.livejournal.com]

Ребе, а как в реляционную модель алгебраические типы данных ложаться? А в xml - ложаться. Сверху можно схему наложить.