PostgreSQL - это свободно распространяемая объектно-реляционная система управления базами данных (ORDBMS), наиболее развитая из открытых СУБД в мире и являющаяся реальной альтернативой коммерческим базам данных.

   PostgreSQL — СУБД с открытым исходным кодом, основой которого был код, написанный в Беркли. Она поддерживает большую часть стандарта SQL и предлагает множество современных функций:

Кроме того, пользователи могут всячески расширять возможности PostgreSQL, например создавая свои

   Определение базы данных PostgreSQL с официального сайта www.postgresql.net. База данных PostgreSQL возникла как проект POSTGRES - хранилище данных в 1986 году при спонсорстве большого количества организаций, которые так или иначе были тогда и сейчас связаны с министерством обороны США. Это было именно хранилище данных, которое не имело ничего общего с реляционными базами данных. Хранилище использовалось в основном для хранения данных различных государственных и научных организаций США и в процессе обучения студентов в различных ВУЗ'ах США.

   В 1994 году в состав программного обеспечения была включена поддержка языка запросов SQL, продукт назвали Postgres95, проект перешел в формат проекта с открытым кодом. За счет удаления из проекта различного узкоспециализированного кода и поддержки первоначального языка запросов PostQUEL, код проекта уменьшился, стал надежнее и быстрее, а использование Postgres95 стало на много удобнее за счет языка запросов SQL.

   В 1996 году было принято решение сменить имя на PostgreSQL, а нумерацию версий начали с версии 6.0, с этого момента база данных стала развиваться и двигаться дальше как полноценная реляционная база данных с открытым кодом, которую портировали на все основные операционные системы - семейства Linux (OpenSuSE, Ubuntu, CentOS, RedHat, Astra, AltLinux и др.) и MS Windows, а так же менее известные ОС, многие из которых возникли и прекратили своё существование за прошедшие годы.

   Специалисты нашей компании работали с различными однопользовательскими и многопользовательскими (серверными) базами данных более 20 лет, у некоторых специалистов есть опыт разработки собственных хранилищ данных на подобие проекта POSTGRES и когда встал вопрос выбора базовой для компании Базы данных, то выбор стоял между PostgreSQL, MySQL, MS SQL и Oracle. Oracle был отвергнут в следствии его платности и технологической тяжести продукта как такового, MS SQL это не только платная база данных, но и база данных работающая только ОС Windows, что влечет за собой дополнительные расходы и ограничения по номенклатуре используемого серверного оборудования. Оставшиеся кандидаты имели массу достоинств - свободно распространяемый продукт, работа практически на любых операционных системах, огромная номенклатура аппаратного обеспечения, в том числе возможно работы на устаревшем оборудовании, которое может быть установлено в офисе, в котором работает всего 2 работника, регулярный выход новых версий и патчей. На этом, на день нашего выбора, совместные достоинства заканчивались и начинались существенные различия, причем различия по параметру оценки у одной базы данных были положительные, а у другой по этому же параметру отрицательные. Из основных параметров следует упомянуть следующие - надежность - сверх надежность PostgreSQL и постоянно рассыпающиеся данные в MySQL, даже в innoDB формате, возможность полноценного серверного программирования и транзакционность в PostgreSQL и зачаточные возможности или полное их отсутствие в MySQL, но выбор был не так прост, у MySQL были свои достоинства - большее количество доступных специалистов на рынке труда и несколько более простое и легкое использование и освоение. Делая выбор, мы решили, что для построения надежных решений, надежность каждого компонента участвующего в решении должна быть максимальной, ибо при определении надежности решения, эффекты ненадежности мультиплицируются и всего один не надежный компонент может вывести весь программно-аппаратный комплекс из строя на длительное время или на всегда. Наличие богатых серверных возможностей позволит снизить затраты на разработку и ускорить работу проектов, а специалисты - дело наживное, тем более что у членов команды есть богаты опыт воспитания из специалистов уровня junior, специалистов уровня middle и senior.

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

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

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

• Данные должны быть обработаны там где находятся, таким образом наша стратегия - написать SQL запрос на несколько десятков строк и получить на сервер приложений или толстый клиент подготовленный набор данных для предоставления пользователю или для использования в какой-либо операции;
• Если для выполнения операции нужно большое количество данных отсутствующих на сервере приложений или толстом клиенте, которые хранятся в базе данных, такие данные должны быть переданы на обработку на сервер базы данных посредством написания сложного SQL запроса, каждом конкретном случае, для обработки данных может быть выбран не запрос, а написана хранимая функция обработчик;
• На плечи сервера базы данных необходимо возложить максимум контрольных функций, освободив программиста от рутинных операций и обеспечив таким образом валидность, достоверность, непротиворечивость и целостность данных, вне зависимости от от каналов поступления этих данных - сервер приложений, толстый клиент, SQL скрипты выполненный из PgAdmin. Для достижения этих целей мы используем:
  • Первичные ключи;
  • Уникальные индексы, самостоятельные и составные;
  • Внешние ключи;
  • check проверки;
  • Триггеры и триггерные функции, осуществляющие сложные проверки, которые не могут быть реализованы с помощью средств перечисленных выше, включая связь с другими сервера с помощью механизмов foreign table, postgres_fdw, dbLink, materialized view;
• Исключение из процесса движения данных лишних посредников, мы используем extension pg_cron для запуска плановых регулярных процедур, как для организации плановых бизнес-процедур, так и для организации межсерверного взаимодействия, в случаях, когда штатные механизмы репликации PostgreSQL не могут быть задействованы или их задействование сопряжено с серьезными трудностями и низкой надежностью решения.

   Нашей компанией реализовано несколько интересных решений для базы данных PostgreSQL;

• Система движения данных от первоисточника к потребителю, которая по сути является системой репликации, но в отличии от штатной, имеет полностью прозрачную структуру, позволяющую в любой момент легко разобраться в причинах возникших проблем, устранить их и тем самым восстановить поток данных. Подробнее
• Система автоматического версионирования данных (ведения истории). Подробнее
• Система распараллеливания исполнения запросов, позволяющая задействовать все ядра сервера для исполнения одного запроса в процессе всего времени выполнения запроса, система фактически увеличивает скорость исполнения запроса в такое количество раз, сколько ядер было задействовано. Подробнее
• Система хранения разреженных данных, позволяющая добавлять к таблицам колонки, в большей части которых данные отсутствуют. Использование системы позволяет сократить затраты дискового пространства и ускорить работу с постоянной частью таблицы. Подробнее
• Система управления доступом к конкретным записям таблицы. Подробнее
• Альтернативная система полнотекстовой индексации. Подробнее

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

Фиксация данных в БД при обработке исключений

Расширение возможностей ограничений-проверок

Секционированная таблица