В некоей СУБД есть типы, значения которых ограничены определенными разработчиком БД диапазонами. Ну там строки ограниченной длины, нумерики ограниченного количества цифр, итд.

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


Пользователи просят разработчиков: можно ли (настраиваемо, чтобы убрать оверхед если понадобится) выводить ошибки на серверной стороне в лог сервера, т.е. если валится где-то в дебрях, а клиентское приложение не умеет толком обрабатывать - чтобы глянуть, что вообще происходит и какие запросы/параметры/данные привели к ошибке.

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


Еще надо заметить, что лог этой СУБД в большинстве случаев не содержит никакой осмысленной информации, в отличие, например от Postgresql, который в дефолтной поставке ошибки и ворнинги пишет в свой лог.
Да и вообще, я предполагаю, что большинство вменяемого серверного софта должно уметь писать в лог инфу с настраиваемой степенью подробности, ибо логи - это первое, куда смотрят, если "что-то работает не так".


Безотносительно к тому, что в опен-сорсе как обычно "жри что дают или плати за доработку/дорабатывай сам" - действительно ли те, кто хотят адекватных средств логирования на серверной стороне, не правы, а разработчики правы?

«Штирлиц бежал по Цветочной улице, а Плейшнеры все падали и падали»

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

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

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

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

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

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

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