Оптимизация времени разработки

В сети Вы можете встретить множество вариантов эмуляции в PostgreSQL возможностей из других СУБД. Некоторые из этих реализаций интересны и даже остроумны. Вот только идеи, заложенные в них, часто способны привести в тупик. Есть много заманчивых ловушек, например, материализованные виды (это вид, который вместо создания набора данных при каждом обращении хранит заранее вычисленный набор данных и обновляет его при каждом изменении исходных данных). Создатели материализованных видов сделали маркетинговый реверанс, предоставив инструмент, который идет вразрез с самой идеей СУБД - независимостью физического и логического уровней представления данных, что бумерангом бьет по основополагающим принципам разработки информационных систем (заметим, что при разумном использовании этот инструмент может быть очень полезен). Есть понятная причина популярности подобного подхода - в любой момент легко можно изменить определение материализованного вида. Выглядит заманчиво, но в "боевой" информационной системе это приведет к катастрофе - множество подобных видов, в которые зашита сложная логика, сделают систему чрезвычайно запутанной и обновление данных медленным. Намного более эффективный путь заключается в создании набора функций, обрабатывающих данные и заполняющих таблицы функционалов. Тогда и загрузка данных в систему и их предобработка будут выполняться быстро, а логика обработки станет прозрачна. Идея изменения алгоритмов обработки в работающей системе вообще выглядит очень странной, ведь это приведет к тому, что все или часть ранее построенных отчетов изменятся. Последствия могут быть непредсказуемы.

Разумеется, если Вы точно знаете что делаете, Вы сможете избежать описанных выше негативных последствий от подобных методов. В любом случае постарайтесь заранее оценивать не только сиюминутное удобство, но и возможные трудности при дальнейшем развитии и сопровождении системы. Результаты обработки данных будут служить ориентиром для ведения бизнеса и требуется очень внимательная разработка и проверка алгоритмов, и первоочередной задачей становится надежность системы. PostgreSQL очень надежная СУБД и в Ваших руках все ключи к созданию надежных систем. А экономия времени и быстрая разработка определяются качеством проектирования системы, используемые инструменты разработки играют в лучшем случае вторичную роль.

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