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

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


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

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


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


Безотносительно к тому, что в опен-сорсе как обычно "жри что дают или плати за доработку/дорабатывай сам" - действительно ли те, кто хотят адекватных средств логирования на серверной стороне, не правы, а разработчики правы?
metaclass: (Default)
Пингбакбот ссылок прислал на Прожекты по среде разработки для баз данных.
Сохранил на всякий случае себе оттуда все, т.к. там сведено и дополнено то, что я про базы данных тут бредил. Cрач разводитьКомментировать там.
metaclass: (Default)
«Штирлиц бежал по Цветочной улице, а Плейшнеры все падали и падали»

Народ срется наобсуждает вечную тему - реализация синхронизации/репликации содержимого баз, применительно к Firebird. Вообще говоря, существуют готовые решения для такого, но, насколько я помню, любое подобное решение в итоге накладывает какие-то не совсем вменяемые ограничения на дизайн базы.
В принципе, мне это тоже предстоит реализовывать, но по той причине, что основную обезъянью работу за меня будет делать кодогенератор, меня больше волнуют теоретические и высокоуровненые аспекты, а думать я над ними сейчас не в состоянии. Скорее всего, сделаю составной ключ "ID базы, ID записи".
metaclass: (Default)
Болезнь окончательно подкосила мозги, поэтому чтобы не думать над работой, приходится думать над всякой ересью.
Конкретно на данный момент пришла в голову такая идея: представим, что GHCi доработали таким образом, что с ним одновременно могут работать по сети множество пользователей. То бишь, изменения вносимые одним пользователям видны другим.
Если к этому добавить транзакции и сброс содержимого памяти на диск, то можно поиметь некий прототип СУБД с хаскелем в качестве языка запросов. Для реального использования нужно будет прикручивать еще права доступа (что я пока с трудом представляю, как делать - вешать на каждое значение в памяти какой-то ACL, что ли) и придумывать способ прикрутить к этому индексы, хотя насчет индексов идея типа такой: к любому значению можно добавить набор функций, которые при изменении значения вычисляются заранее и результат запоминается. Типа мемоизации заранее.

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

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

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

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

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

И таки что тогда хорошего в бизнес-логике на стороне СУБД?
metaclass: (Default)
Спор про F# (там рекаптча если шо)

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

Т.е. вообще-то ее написать можно, через Reflection, но 1) это все только благодаря дотнету, но никак не системе типов; 2) это противоречит духу статической типизации и является способом стрелять себе в ногу.

Никак не могу человеку объяснить разницу между статической типизацией и натягиванием совы на глобус реализацией динамической типизации поверх языка со статической, чем занимаются 90% либ доступа к БД (все эти ADO.NET, ODBC, JDBC, BDE и прочая).

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 Jul. 25th, 2017 12:40 am
Powered by Dreamwidth Studios