Linuxformat - Вклад участника [ru]

Обсуждение участника:PonElA

2008-03-19T21:25:40Z

PonElA:

Спасибо за статью о PostgreSQL, я отвечаю за 89 номер и дальше сам доведу оформление статьи до ума (там проблемы с пробелами в кодовых вставках)

: Хотел сказать то же самое в отношении других номеров журнала – поскольку они все заняты, Вам следует уточнять этот вопрос у ответственного за номер (через страницу обсуждения) или в редакции. Кстати, мы заметили, что текст отличается от журнального – откуда он? --[[Участник:WikiSysop|WikiSysop]] 08:03, 18 марта 2008 (MSK)

:: Источник статьи http://www.inp.nsk.su/~baldin/PostgreSQL/index.html

LXF91:PostgreSQL

2008-03-13T12:01:10Z

PonElA: Новая: В заключительной статье цикла Евгений Балдин хочет остановиться на моментах, с которыми стоит разобр...

В заключительной статье цикла Евгений Балдин хочет остановиться на моментах, с которыми стоит разобраться поглубже.

:Устреми свои мысли на высшее Я, свободный от вожделения и себялюбия,
:исцелившись от душевной горячки, сражайтесь, Арджуна!
:Зеркало.
::Понедельник начинается в субботу.

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

==Резервное копирование==

Если уж завели хранилище информации, то его надо беречь. При этом навязчивая идея на тему порчи данных, переходящая в манию, является обязательной характеристикой нормального администратора базы данных. Только в этом случае можно подстелить соломы в нужном месте, до того как подскользнуться. И то, что при этом весь дом будет покрыт высушенной травой обычные издержки производства.
===pg_dump/pg_restore===
Просто копировать физические файлы базы данных не самый лучший способ для бэкапа, потому что на момент операции придётся как минимум остановить сервер. Для создания консистентной копии базы данных проще всего воспользоваться программой pg_dump (man pg_dump), которая работает как обычный клиент:
> pg_dump −Fc база данных > файл резервной копии
Опция -Fc определяет формат резервной копии как custom. В этом случае сохраняются не только SQL-структуры, но и большие объекты (lobj).

Для восстановления базы данных из её резервной копии используется зеркальная
процедура pg_restore (man pg_restore):
> p g _ r e s t o r e −d новая база данных файл резервной копии

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

Так как pg_dump и pg_restore сконструированы с учётом работы в конвейере, то их удобно использовать в скриптах. Резервная копия представляет из себя в основном ASCII-файл, поэтому при формировании процедуры бэкапа/восстановления имеет смысл предусмотреть фильтр для сжатия данных, например, bzip2.

При восстановлении больших объектов (lobj) очень важно, что pg_restore отработало без ошибок от начала и до конца. Причина этого в том, что при восстановлении больших объектов создаётся временная таблица, где есть перекодировка из старой нумерации OIDов в новую. Если в процессе восстановления произошло прерывание, то эта таблица теряется и ссылки на большие объекты в таблицах не обновляются. В результате большие объекты в базу данных загружаются, но ссылки на них отсутствуют. Это один из примеров того, как нестандартные расширения могут приводить к неудобствам.

===Непрерывный бэкап===
pg_dump умеет создавать резервную копию особо не мешая функционированию базы данных, так как это всего на всего ещё один клиент. Есть одна неприятность в классическом подходе резервирования: информация между бэкапом и крахом базы данных теряется. Иногда это терпимо, так как подобное случается редко, но есть случаи, когда потерянные запросы означают потерянные деньги в полном смысле
этого слова. И здесь на помощь приходит журналирование транзакций. Находка для параноика.

Организация непрерывного бэкапа довольно сложная процедура и для её реализации следует обратиться к разделу документации, который так и называется Online backup and point-in-time recovery (PITR) . В этой главе представлено пошаговое руководство к действию длинной чуть меньше пяти тысяч слов, что составляет около пятнадцати страниц текста на A4.

Основная идея заключается в архивации журнала транзакций. Формально все действия PostgreSQL можно представить как последовательные записи в этом журнале. На диске журнал транзакций разбивается на независимые файлы или сегменты (segment ﬁles) размер которых по умолчанию равен 16 Мб. PostgreSQL можно настроить на копирование сегментов в место для бэкапа (параметр archive_command в postgresql.conf). При этом нет необходимости хранить абсолютно все записи. Достаточно оставлять только те, которые были сделаны после бэкапа. Для локализации времени, которому соответствует резервная копия сделанная во время процедуры бэкапа, используются хранимые функции pg_start_backup/pg_stop_backup.

При восстановлении можно восстановить не только текущее состояние базы данных, но и состояние в котором она была на указанный момент времени. Естественно всё лимитируется объёмом сохранённых сегментов. Таким образом при желании можно организовать своеобразное путешествие в прошлое (point-in-time recovery).

==Переезд на новую версию PostgreSQL==
По умолчанию при исполнении pg_dump на выходе получаются SQL-команды. Так что для восстановления можно воспользоваться psql, указав файл резервной копии с помощью ключика -f. То есть структура резервной копии зависит только от версии SQL которую поддерживает данный сервер. Это позволяет достаточно легко обновлять PostgreSQL даже если изменяется представление данных внутри самого PostgreSQL, так как SQL и в Африке SQL.

Поэтому переезд с версии на версию гарантировано можно выполнить в четыре этапа:
# сделать резервную копию с помощью pg_dumpall,
# остановить старый сервер,
# запустить новый сервер,
# восстановить базу данных с помощью pg_restore или psql.

Если меняется только минорная версия PostgreSQL (последняя цифра в версии), то в принципе можно упустить этап 1 и 4. Но в любом случае не следует забывать о фобии потери данных. В принципе можно исключить пункты 2 и 3 воспользовавшись конвейером:
> pg_dump −h h o s t 1 БД | p s q l −h h o s t 2 БД host1 и host2
компьютеры с какого и на какой, соответственно, переезжает база данных.

==Репликация слонов==
База данных подразумевает централизацию: всё складывается в одно место. Это может стать проблемой. Некоторые проблемы не решаются, но если требуется всего на всего ускорить доступ на чтение, то репликация базы данных может оказаться спасением. Побочным эффектом репликации является повышение надёжности базы, так как число консистентных копий данных увеличивается. Создание кластера баз данных это глобальный инструмент для решения многих проблем, но и сложности в управлении кластером также будет предостаточно.

Для репликации PostgreSQL существует несколько решений, как закрытых<ref>Например, http://www.commandprompt.com/products/mammothreplicator Mammoth PostgreSQL + Replication.</ref>, так и свободных. Самой популярной свободной системой репликации является Slony I (http://slony.info/). Slony I поддерживает master/slaves репликацию
<ref>
Имя Slony-II зарезервировано для версии, которая будет поддерживает multi-master режим.
На текущий момент будущее этой версии довольно туманно. Организовать надёжное решение для требуемого режима очень сложно в силу большого количества принципиальных проблем [http://www.dbspecialists.com/presentations/mm_replication.html dbspecialists.com].
Для реализации multi-master режима пользователем PostgreSQL поддерживает отложенные транзакции (two-phase commit). Two-phase commit реализуется с помощью SQL-запросов PREPARE TRANSACTION и COMMIT PREPARED.
</ref>.
Возможные преимущества которые можно получить, наладив репликацию:

* Организуются дополнительные копии данных, которые никогда лишними не бывают. Помним о благотворном влиянии паранойи.
* Разгружается центральный сервер, теперь он может заниматься действитель но важными делами не отвлекаясь на мелочи.
:Например, процедура полного бэкапа довольно ресурсоёмкая. Вполне можно поручить это задание одному из вспомогательных серверов. Аналогично можно организовать сервер, который имеет очень длинный лог транзакций, чтобы можно было откатиться максимально далеко по времени в случае необходимости.
* Можно перенести вспомогательный сервер поближе к клиенту, чтобы не было проблем со временем, которое уходит на подсоединение к базе данных,
* Дополнительные сервера позволяют таки доступиться к данным, даже если связь с центральным сервером полностью потеряна.

Вспомогательные сервера вовсе не обязаны получать обновления непосредственно с главного сервера (Master to multiple cascades Slaves). Любой сервер, который получает данные из надёжного источника может быть сконфигурирован так, чтобы рассылать эти данные далее по цепочке. Данная особенность позволяет легко масштабировать систему. Развернуть и запустить репликацию можно не останавливая центральный сервер.

Для для привязки к событиям INSERT/DELETE/UPDATE используются триггеры PostgreSQL. Выполнения действий реализуются через хранимые процедуры. Слежением за выполнением репликацию занимается системный демон slon, то есть для работы он должен быть запущен на каждом из узлов кластера. Администрирование осуществляется посредством командного процессора slonik.

Административная утилита slonik реализована как программа, ориентированная на выполнение в командной строке и в скриптах. Синтаксис команд воспринимаемых slonik’ом напоминает SQL. Команды следует передавать на STDIN. Перед исполнением запроса slonik анализирует синтаксис и в случае наличия проблем, команда не исполняется и выдаётся сообщение об ошибке.

Подробно о настройке кластера можно прочитать в документации к пакету. На русском есть написанное Евгением Кузиным пошаговое руководство, правда возможно уже устаревшее: http://www.kuzin.net/work/sloniki-privet.html. В случае возникновения проблем для начала следует поискать решение в стандартном [http://linuxfinances.info/info/faq.html FAQ].

В качестве побочного эффекта репликации её можно использовать при обновлении версии сервера PostgreSQL. Это удобно когда объём базы данных становится очень большой и останавливать её на момент смены версии не очень бы хотелось.

'''Принципиальные ограничения''' Большие объекты не реплицируются. Это происходит потому, что Slony I работает на триггерах, а операции с большими объектами триггерным механизмом не отлавливаются. То есть реплицируются только таблицы и последовательности. Для того чтобы репликация работала автоматически лучше отказаться от больших объектов, благо существуют соответствующие бинарные типы данных, вполне годящиеся на их замену.

На начало марта 2007 года последняя версия Slony I была 1.2.2. Для функционирования этой версии необходим PostgreSQL старше 7.3.3, так как требуется обязательная поддержка пространства имён (namespace). При репликации предполагается, что все базы данных создавались с указанием одной и той же кодовой страницы
<ref>
Это замечание относится к ключику --encoding команды createdb.
</ref>
и текущая кодовая страница с ней совпадает. Задача временной синхронизации серверов выходит за рамки функционирования Slon’ов для этого следует озадачиться созданием специальной службы (Network Time Protocol www.ntp.org).

Процедуры изменения схемы базы данных (database schema, DDL Язык определения данных), следует производить посредством передачи команд через slonik посредством префикса EXECUTE SCRIPT. Это гарантирует, что, например, изменение числа столбцов в таблице произойдёт во всём кластере до того как туда начнут добавляться данные.

==Локаль==

Локаль (locale) это набор соглашений, специфических для отдельно взятого языка в отдельно взятой стране
<ref>
В общем случае говорить, что локаль определяется только страной, неправильно. Например, в Канаде могут быть определены две локали: язык "Канада/Английский"и язык "Канада/Французский". Аналогично язык "Великобритания/Английский"не эквивалентен языку"Американский/Английский".
</ref>.
Локаль и кодовая страница базы данных выбирается при её создании с помощью команды initdb:
> i n i t d b −−l o c a l e=ru_RU .UTF−8 −−l c −numeric=POSIX
В зависимости от локаль результат выполнения SQL-запросов может отличаться.Например, это проявляется при сортировке текстовых данных или при выполнении функций upper/lower/initcap.

Для корректной работы базы данных с устанавливаемой локалью необходимо, чтобы данная локаль поддерживалось системой. Вывести список поддерживаемых локалей можно с помощью команды locale -a.

Так как локализация проводилось Олегом Бартуновым, то все русские кодовые страницы поддерживаются. При наборе русских текстов можно использовать следующие из них: KOI8 (aka KOI8R), WIN1251 (aka WIN), WIN866 (aka ALT), ISO_8859_5, UTF8 (aka Unicode) и MULE_INTERNAL<ref>
То, что используется в emacs.</ref> .

Кодовая страница клиента может отличаться от кодовой страницы сервера. Например в сессии psql кодовую страницу можно установить следующим образом:
mydb−> \ enco di ng KOI8R
mydb−> show CLIENT_ENCODING;
client_encoding
−− −−−−−−−−−−−−−−−
KOI8R
( 1 запись )
При этом на самом деле используется PQsetClientEncoding() функция libpq, которая в свою очередь выполняет SQL-запрос SET CLIENT_ENCODING TO.

После выставки кодовой страницы клиента PostgreSQL выполняет автоматическое преобразование запросов между кодовыми страницами сервер/клиент, если это конечно возможно. Для русских кодовых страниц все варианты преобразований имеются. При желании с помощью SQL-запрос CREATE CONVERSION можно создать свою таблицу преобразования.

==VACUUM/ANALYZE==
Администрируя PostgreSQL, следует помнить, что для его нормального функционирования следует регулярно мыть руки и чистить зубы , то есть исполнять команды VACUUM и ANALYZE. Это необходимо по той причине, что иначе не получится заново использовать дисковое пространство, которое занимают ранее удалённые или изменённые строки и не удастся обновить статистику для планировщика запросов. И то и другое отрицательно сказывается на эффективности использования ресурсов и производительности запросов.

Начиная с версии PostgreSQL 8.1 сервер может самостоятельно автоматически запускать ещё один системный процесс, который, соответственно, так и называется autovacuum daemon. Все настройки для этого процесса хранятся в postgresql.conf. К значениям этих параметров следует отнестись крайне внимательно.

Если по каким-то причинам демон было решено не запускать, то в любом случае необходимо производить сборку мусора и набор статистики в ручную с помощью команды vacuumdb (man vacuumdb):
> vacuumdb −ze
VACUUM ANALYZE;
VACUUM

==Мониторирование активности базы==
Текущую активность базы данных легко оценить с помощью команды ps:
> ps auxww | g r ep ^ p o s t g r e s
p o s t g r e s . . . p o s t m a s t e r −i
postgres ... postgres : writer process
postgres ... postgres : stats buffer process
postgres ... postgres : stats c ol l e c t or process
p o s t g r e s . . . p o s t g r e s : b a l d i n mydbase [ l o c a l ] i d l e
Так как для каждого клиента создаётся своя копия процесса postmaster, то это позволяет подсчитать число активных клиентов. Статусная строка даёт информацию о состоянии клиента. Фразы writer process, stats buﬀer process и stats collector process соответствуют системным процессам, запущенным самим PostgreSQL при старте. Пользовательские процессы имеют статусную строку вида
postgres: пользователь база хост статус
пользователь , база и хост соответствуют имени пользователя пользователь подсоединявшегося к базе база с компьютера хост . статус может принимать следующие параметры:
* '''idle''' ожидание команды от клиента,
* '''idle in transaction''' ожидание команды от клиента внутри транзакции (между BEGIN и окончанием транзакции),
* '''SQL-команда''' выполняется эта команда, например, SELECT,
* '''waiting''' ждём когда разблокируется занятая другим процессом таблица.

Если в postgresql.conf разрешён сбор статистики (опции stats_start_collector и stats_row_level), то информация об активности базы данных собирается в специальных системных таблицах. Ту же информацию, что получается с помощью ps можно извлечь из таблицы pg_stat_activity, а в pg_stat_all_tables лежат данные о числе обращений к каждой из таблиц базы. Подробнее обо всех имеющихся таблицах можно прочитать в главе Viewing Collected Statistics стандартной документации. Информация собранная статистическим сборником может оказаться полезной для оценки эффективности базы данных и запросов. Например, pg_stat_all_indexes поможет оценить эффективность и частоту использования индексов при реальной работе. Подробную информация о блокировках можно почерпнуть в таблице pg_locks.

==log==
Когда что-то работает бывает полезно иметь обратную связь. Поэтому лучше чтобы журнальный файл (log) существовал. Создавать ли лог-файл самостоятельно или воспользоваться службой syslog это зависит от обстоятельств. Следует только учитывать, что syslog на каждой записи производит операцию sync, что может серьёзно замедлить доступ к диску на котором лежит журнальный файл. Это так же следует учитывать.

==Послесловие==
{{Врезка|Выравнивание=right
|Ширина=300px
|Заголовок=<div style="background-color:#ABCDEF;" align="center">'''К вопросу о происхождении Слонов'''</div>
|Содержание=В документации к пакету Slony I для англоязычной аудитории идёт специальное разъяснение:
* слон это русский elephant,
* множественная форма от слова слон это слоны,
* слоник это маленький elephant.}}

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

Далеко не всё упомянуто и далеко не все рассказано достаточно подробно. Та же тема полнотекстового поиска просто сама по себе может занять не одну главу. Картографические и астрофизические типы данных так же имеют за собой фундаментальную базу и интересные сферы приложения. PostgrеSQL это хранилище данных, но за каждым типом данных своя уникальная история и инструкция по использованию. Тема супербольших баз данных, где кластеризация является обязательной суперсложна и не менее интересна. Переход к многопроцессорным архитектурам увеличивает сферы применимости баз данных. Я не сильно удивлюсь, что угрозы, сделать из файловой системы специализированную базу данных, воплотятся в обычную базу данных общего применения, которая будет хранить в себе файловую систему. Хотя бы пользовательские документы, где не особо важна скорость доступа, но естественный полнотекстовый поиск будет весьма кстати. В любом случае в будущем без баз данных делать нечего и PostgreSQL там будет
наверняка. Присоединяйтесь.

Термин Slony I это реверанс в сторону Вадима Михеева, который создал прототип для системы репликации rserv на языке perl. Проект был спонсирован фирмой Aﬁlias (http://afilias.info), которая наняла для этого одного из основных разработчиков PostgreSQL Яна Вейка (Jan Wieck). Со слов Яна с самого начала проект планировался как программа с открытыми исходниками, которые всегда были дотупны публично. Это яркий пример того, что коммерческие фирмы могут сделать весомый вклад в открытые разработки без каких-либо задних мыслей, как участники свободного сообщества.

==Примечания==
<references />

LXF90:PostgreSQL

2008-03-13T11:36:25Z

PonElA: /* Примечания */

'''PostgreSQL. ЧАСТЬ 5: Настройка PostgreSQL'''

PostgreSQL в фундаменте «1С:Предприятия»? В свое время эта новость произвела фурор в мире Linux, а сегодня Евгений Балдин покажет, что для этого было сделано, и расскажет, как настроить PostgreSQL для выполнения этих или любых других задач

: - Между прочим, - сказал Роман громко, - уже в
:течение двух минут я пытаюсь его пассивизировать,
:и совершенно безрезультатно
::Понедельник начинается в субботу АБС
"Тюнинг" - это не операция - это образ жизни. Очевидно, что когда необходимые характеристики можно улучшить несколькими способами, то всеми способами их и надо улучшать. Но опять же следует помнить, что избыточная и ранняя оптимизация корень многих зол. Если система работает и не кашляет , то может быть не стоит её настраивать?

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

Как и для всякой программы, работающей с большим объёмом данных, дисковая подсистема является для PostgreSQL определяющей. Поэтому если есть возможность, то лучше вложиться именно в неё. В противоположность дисковой подсистеме процессор нагружается не очень сильно. Поэтому для сервера достаточно, чтобы процессор просто был, хотя лучше чтобы он был не один. Если денег на покупку хорошего SCSI диска нет, то следует вложиться в память.

К вопросу о дисках можно сказать, что чем их больше тем лучше. По возможности следует выделить отдельный диск для журнала транзакций (pg_xlog). Избыток дисков так же позволит собрать из них RAID. Хоть никто и не отменяет бэкапа, но дополнительная избыточность для дисковой подсистемы, как и источники бесперебойного питания, сэкономят массу сил и нервов.

Относительно недорогие системы снабжены дешёвыми встроенными RAID-контроллерами на четыре диска. Не следует использовать эти контроллеры, а лучше настроить софтверный RAID и не надо использовать RAID 5
<ref>
Один диск в массиве выделяется под контрольные суммы
</ref>
для небольшого числа дисков. До 6 дисков включительно лучше RAID 1+0
<ref>
зеркалирование (1) + объединение (0)
</ref>
. Избыточность во всём это только похоже на паранойю.

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

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

==Конфигурационные файлы==
Настройка конфигурационных файлов не единственный способ настройки сервера базы данных. Умолчания можно изменить непосредственно при сборке из исходников. Значения можно передавать непосредственно серверу postmaster в командной строке, используя ключик -с. Так же можно определить переменную окружения PGOPTIONS, а значения некоторых переменных можно изменить прямо в процессе выполнения запросов.

Концентрация внимания на конфигурационных файлах объясняется тем, что в любом случае их придётся настраивать. По умолчанию PostgreSQL сконфигурирован в расчёте на минимальное потребление ресурсов, и это не может не сказаться на скорости. Что подходит для локальной записной книжки не годится для боевого сервера.

Все настройки очень подробно описаны в документации. Для любителей выжимать из программы всё существует специальный список рассылки psql-performance: [http://archives.postgresql.org/pgsql-performance/ archives.postgresql.org]. В документации на странице Power PostgreSQL http://www.powerpostgresql.com/Docs также можно найти некоторое количество полезных подсказок.

Для настроек PostgreSQL используются файлы:
:'''pg_hba.conf''' - политика доступа и идентификации пользователей,
:'''postgresql.conf''' - собственно говоря, настройки сервера.

===pg_hba.conf===
Часто для локальных нужд при использовании PostgreSQL в качестве своей личной записной книжки, склада данных или даже помойки не требуется открывать сетевой доступ к базе данных. По умолчанию PostgreSQL настроен так, что каждый локальный пользователь может подсоединиться к базе совпадающей по названию с регистрационным именем клиента, при условии что такая база данных уже создана.

Но это не значит, что так бывает всегда. PostgreSQL предоставляет свои механизмы для управления пользователями с помощью тройки команд CREATE USER, DROP USER и ALTER USER. В случае не совпадающих регистрационных имен в PostgreSQL и в системе или при доступе к базе данных с других компьютеров необходимо обговорить правила доступа к данным на сервере.

Для настройки политики доступа к серверу волей-неволей придётся заглянуть в файл pg_hba.conf
<ref>
hba host-based authentication.
</ref>
. Тело файла представляют из себя однострочные записи, каждая из которых регулирует правила получения доступа для конкретной машины или для целой группы IP. Файл pg_hba.conf выглядит примерно следующим образом:

----
:Разрешаем доступ через локальные unix−сокеты абсолютно
:всем пользователям к базам данным, совпадающим по названию
:с регистрационными именами
local all all i d e n t sameuser
:Доверяем пользователю a l e x с указанного IP безгранично
:в рамках базы данных pho t o s
host pho t o s alex 130.255.204.48/32 trust
:Требуем пароль от пользователя b a l d i n при доступе с
:компьютеров из сети 1 2 8 . 1 3 8 . 2 4 2 . 1 9 2 / 2 7 к базам данных
:data и pho t o s
h o s t s s l data , pho t o s b a l d i n 1 2 8 . 1 3 8 . 2 4 2 . 1 9 2 / 2 7 md5
----

В файле по умолчанию присутствует подробная информация о формате записей,
первое поле которых определяет тип записи:
* local эта запись определяет политику для локального доступа через локальные UNIX-сокеты.
* host эта запись определяет политику для сетевого TCP/IP соединения и годится для соединений с использованием SSL и без него. Для того чтобы можно было доступаться к базе данных по сети необходимо правильно настроить listen_addresses в postgresql.conf.
* hostssl определяется политика для сетевого соединения с обязательным использованием SSL.
* hostnossl антипод hostssl.

Второе поле представляет из себя имя базы данных для которой определяется политика. Имя all зарезервировано для всех баз данных, а имя sameuser для базы данных, совпадающей с именем пользователя. Имена баз данных можно перечислять через запятую. Так же в качестве имени можно добавить имя файла со списком баз, разделённых запятой или пробелами. Для этого к имени файла следует добавить символ @ в качестве префикса.

Третье поле имя пользователя. Как и в случае имён баз данных можно работать со списками. Имя all зарезервировано для всех пользователей. Так же доступ можно открыть для группы пользователей (role), для этого перед именем группы следует поставить знак + .

Следующие ноль (в случае записи local), одно (нотация CIDR
<ref>
Classless Inter-Domain Routing
</ref>
) или два поля (адрес и сетевая маска) занимает сетевой адрес компьютера или подсети для которого настраивается политика доступа.

Предпоследнее обязательное поле отведено под метод авторизации:
* '''trust''' - полностью доверяем этому клиенту.
* '''reject''' - отказ в доступе.
* '''ident''' - доступ по регистрационной записи клиента. Часто применяется для локальных соединений. RFC 1413.
* '''md5''' - авторизация по паролю зашифрованному с помощью алгоритма md5. Если клиент использует библиотеку для доступа к PostgreSQL версии старше 7.2, то вместо метода md5 следует использовать метод crypt. Пароль при желании и значительной степени бесшабашности можно передавать открытым текстом с помощью метода password.
* '''pam''' - авторизация с помощью Pluggable Authentication Modules. Этот сервис предоставляется операционной системой. Подробнее о PAM написано здесь: http://www.kernel.org/pub/linux/libs/pam/.
* '''krb4 и krb5''' - авторизация с использованием механизма Kerberos версии 4 и 5, соответственно. Это индустриальный стандарт авторизации. То есть, кому надо тот знает что это такое.

После метода ему можно передать опции в последнем необязательном поле.

===postgresql.conf===

Настройки в postgresql.conf разбиты по группам и подробно задокументированы прямо в файле. Здесь будут описаны не все настройки, но важнейшие из них будут отмечены.

====Настройка соединений и авторизация (Connections and Authentication)====

Политика авторизации настраивается в pg_hba.conf. Здесь же собраны в основном технические параметры.
* ''Настройка соединений (connection settings'').
** '''listen_addresses''' После настройки pg_hba.conf можно и нужно смело устанавливать * слушаем все интерфейсы, которые есть в наличии. По умолчанию (localhost) запросы принимаются только от локальных пользователей в том числе и через интерфейс обратной связи (loopback-интерфейс 127.0.0.1).
** '''port''' Номер порта, который слушает сервер в ожидании соединений. По умолчанию он равен 5432.
** '''max_connections''' Число клиентов, которые могут подсоединяться к базе данных одновременно не может быть бесконечным. Каждое подсоединение порождает ещё один процесс postmaster, что, естественно, требует ресурсов. Средней паршивости современный однопроцессорный компьютер со стандартным наполнении без особых проблем может обслуживать 100-200 соединений, но, например, 600 активных соединений будут уже явной проблемой. Любая попытка подсоединиться сверх указанного лимита приведёт к отказу от обслуживания. Плохо написанная программа в цикле открывающая, но не закрывающая за собой оединения, легко создаст проблему. Если число клиентов жёстко ограничено, то имеет смысл уменьшить этот параметр до минимально возможного значения.
** '''superuser_reserved_connections''' Число соединений, которые зарезервированы для суперпользователя, чтобы он мог всегда зайти, разобраться в чём дело, а затем принять меры. Не стоит совсем отказываться зарезервированных соединений, причём одного зарезервированного соединения может оказаться не достаточно 2 это минимум.
* ''Безопасность и авторизация (security and authentication)''
** '''authentication_timeout''' Время ожидания для прохождения авторизации в секундах. По умолчанию это время равно одной минуте. Не позволяет клиенту зависнуть и заблокировать ресурс соединения на очень долгое время.
** '''ssl''' Разрешается доступ через ssl. Для работы через SSL необходимо создать публичный ключ и сертификат. Это требует некоторых усилий, зато позволяет немного успокоить себя на тему безопасности сетевых соединений.

====Управление ресурсами (Resource Consumption)====

Правильная оценка имеющихся ресурсов путь к эффективном планированию. А эффективное планирование позволяет в процессе работы не сильно увеличивать окружающую нас энтропию и в то же время добиваться поставленной цели. Очевидные истины.
* ''Память (memory)''
** '''shared_buﬀers''' Объём совместно используемой памяти, выделяемой PostgreSQL для кэширования данных, определяется числом страниц (shared_buﬀers) по 8 килобайт каждая. Естественно, данные умеет кэшировать не только сам PostgreSQL, но и операционная система сама по себе делает это очень неплохо. Поэтому нет необходимости отводить под кэш всю наличную оперативную память. Оптимальное число shared_buﬀers зависит от многих факторов, поэтому проще для начала принять следующие ориентиры:
*** Обычный настольный компьютер с 512 Мб и небольшой базой данных 8–16 Мб или 1000–2000 страниц.
*** Не сильно выдающийся сервер предназначенный для обслуживания базы данных с объёмом оперативной памяти 1 Гб и базой данных около 10 Гб 80–160 Мб или 10000–20000 страниц.
*** Сервер посерьёзнее с несколькими процессорами на борту, с объёмом памяти в 8 Гб и базой данных занимающей свыше 100 Гб обслуживающий несколько сотен активных соединений одновременно 400 Мб или 50000 страниц.
** '''work_mem''' Под каждый запрос можно выделить личный ограниченный объём памяти для работы. Этот объём может использоваться для сортировки, объединения и других подобных операций. При превышении этого объёма сервер начинает использовать временные файлы на диске, что может существенно замедлить скорость обработки запросов. Предел для work_mem можно вычислить, разделив объём доступной памяти (физическая память минус объём занятый под другие программы и под совместно используемые страницы shared_buﬀers) на максимальное число одновременно используемых активных соединений. При необходимости, например, выполнения очень объёмных операций, допустимый лимит можно изменять прямо во время выполнения запроса. Поэтому нет нужды изначально задавать теоретический предел.
** '''maintenance_work_mem''' Эта память используется для выполнения операций по сбору статистики (ANALYZE), сборке мусора (VACUUM), создания индексов (CREATE INDEX) и добавления внешних ключей. Рамер выделяемой под эти операции памяти должен быть сравним с физическим размером самого большого индекса на диске. Как и в случае work_mem эта переменная может быть установлена прямо во время выполнения запроса.
** '''max_prepared_transactions''' Определяет максимальное число подготовленных транзакций (команда PREPARE TRANSACTION). Подготовленные транзакции выполняются, но результат их не будет доступен пока их не подтвердят (COMMIT). Так же можно такие транзакции и отклонить (ROLLBACK). Если эта сущность нигде не используется, то переменную можно занулить.
* ''Карта неиспользованного пространства (free space map)'' При удалении записи не удаляются физически, а только помечаются как удалённые. Именно таким образом мусор и собирается.
** '''max_fsm_pages''' Для целей сборки мусора следует знать где этот мусор находится. Число страниц отведённых под эту задачу должно быть больше, чем число удалённых или изменённых записей между сборками мусора (VACUUM). Если страниц достаточно выполнение жёстких оптимизирующих операций, таких как VACUUM FULL или REINDEX никогда и не понадобится. Так как объём требуемой для этого памяти не очень большой (по 6 байт на страницу), то жадничать не стоит. Проще всего узнать необходимое число max_fsm_pages запустив, VACUUM VERBOSE ANALYZE.
** '''max_fsm_relations''' Число таблиц для которых создаются карты неиспользованного пространства. По умолчанию это число равно 1000. В случае большего числа используемых таблиц это значение можно и нужно увеличить, тем более что на каждую таблицу требуется всего по семь байт.
* ''Системные ресурсы (kernel resource usage)''
** '''preload_libraries''' Если для исполнения запроса требуется загрузить какую-либо разделяемую библиотеку, то действует правило: загружаем при первом использовании , что замедляет исполнение самого первого такого запроса. Это можно обойти, загрузив необходимые библиотеке при старте сервера, то есть воспользоваться формулой: память в обмен на скорость. Таким образом можно подгрузить разделяемую библиотеку для используемых в запросах процедурных языков.
* ''Оценка стоимости сборки мусора (cost-based vacuum delay)'' Немного подробнее про сборку мусора будет рассказываться далее. Обычно нет необходимости заглядывать в этот раздел, так как сборка мусора (VACUUM) и анализ (ANALYZE) выполняются достаточно быстро.
* ''Запись в фоне (background writer)''

Начиная с версии PostgreSQL 8.0 вместе с основным сервером стартует процесс для записи данных в фоне. При выполнении запроса нет необходимости ждать самого акта записи, так как это гарантировано сделает background writer.

====Журнал транзакций (Write Ahead Log)====

Наличие журнала транзакций или WAL (write ahead log) позволяет увеличить скорость выполнения операций требующих изменения данных в следствии того, что в журнал информация об изменениях пишется последовательно, а изменения в самих таблицах могут быть отложены до лучших времён своеобразный кэш только на диске. Если же база данных используется в основном для чтения, то в журнале транзакций нет особой необходимости, но это не повод от него отказываться.
* ''Настройки (settings)''
** '''fsync''' По умолчанию эта опция включена (true). В этом случае PostgreSQL пытается записать данные на диск физически. Это на самом деле не такая уж и простая операции, так как кэши существуют не только в системе, но и в контроллерах и в дисках. Вполне можно представить себе такую ситуацию, что слишком умный диск для увеличения своей производительности в тестах рапортует о том, что данные записаны, а при перебое с электричеством выясняется, что это была просто шутка. Сбои самого сервера не приводят к порчи данных, но сервер живёт в окружении далеко не идеальной операционной системе, которая в свою очередь управляет далеко не идеальными физическими устройствами. Так что проверенное железо, источники бесперебойного питания, бэкап, бэкап и ещё раз бэкап.<br/>
Если Вы доверяете своему железу, то эту опцию можно выключить. Здесь можно поменять немного безопасности на скорость. Хотя более оптимальным решением является перенос журнального файла на отдельный быстрый диск. То есть прикупить скорость за деньги.
* ''Контрольные точки (checkpoints)'' По свершению каких-то определённых условий или истечению контрольного времени сервер гарантировано переносит данные, записанные в WAL непосредственно в таблицы, даже если очень сильно занят на других запросах.
** '''checkpoint_segments''' Объём кэша на диске. Физический объём места на диске, требуемый под кэш вычисляется по формуле (checkpoint_segments × 2 + 1) × 16 Мб. Следует выделить столько, сколько не жалко, осознавая, что 32 сегмента займёт на диске свыше 1 Гб.
** '''checkpoint_timeout''' Время, через которое WAL очищается насильно. По умолчанию 300 секунд.
** '''checkpoint_warning''' Если кэш а диске заполняется быстрее чем число секунд checkpoint_warning, то посылается предупреждение, которое будет передано в журнальный файл. Это намёк, что кэш на диске следует увеличить.
* ''Архивация (archiving)''
** '''archive_command''' Для целей создания непрерывного резервного копирования (возможность для настоящих параноиков) журнал необходимо копировать куда-то ещё. Здесь должна быть команда, которая будет использоваться системой для копирования данных. Подробности следует искать в документации в разделе On-line backup and point-in-time recovery (PITR).

====Планирование запросов (Query Planning)====

Здесь можно повлиять на логику действия планировщика. Возможно конкретно для Вашей системы значения по умолчанию не оптимальны, но менять их стоит только после серии тестов для выявления более оптимальной конфигурации под конкретную платформу и конкретные запросы. В большинстве случаев углубляться в тонкости настроек из этого раздела имеет смысл только в случае очень изощрённых запросов.
* Методология планировщика (planner method conﬁguration) В этом разделе перечислены алгоритмы, которые можно использовать для извлечения данных. Для целей тестирования какие-то из них можно отключить.
* Оценочные константы (planner cost constants)
** '''eﬀective_cache_size''' PostgreSQL в своих планах опирается на кэширование файлов, осуществляемое операционной системой. Этот параметр соответствует максимальному размеру объекта, который может поместиться в системный кэш. Установка этого параметра не приводит к увеличению выделяемой памяти. Это значение используется только для оценки. eﬀective_cache_size можно установить в 1/3 от объёма имеющейся в наличии оперативной памяти, если вся она отдана в распоряжение PostgreSQL.

====Сообщения об ошибках и событиях (Error Reporting and Logging)====

Оптимизация возможно только в случае обратной связи. Сервер PostgreSQL может много чего про себя рассказать. Этот раздел настроек посвящён тому, как правильно его об этом попросить.
* ''Местоположение журнального файла (where to log)''
** '''log_destination''' Здесь можно выбрать способ записи в журнальный файл: stderr или syslog. Метод stderr хорош для тестирования, но по хорошему журналированием должна заниматься специальная служба, а это нас приводит к необходимости изучить что такое syslog. В случае выбора метода stderr придётся определить директорию для журнального файла (log_directory), имя журнального файла (log_ﬁlename) и другие параметры (log_rotation_age, log_rotation_size, log_truncate_on_rotation) свойственный службе журналирования. В случае выбора метода syslog настроить его с помощью syslog_facility (необходимо знать как пользоваться syslog) и syslog_iden идентификационный префикс для сообщений получаемых от PostgreSQL.
* ''По какому случаю создаём запись (when to log)'' Обычно, нет необходимости записывать в дневник информацию о каждом чихе, но при серьёзном разбирательстве данные о числе чихов в секунду и их классификация могут подтолкнуть в нужном направлении. Каждому событию можно присвоить какой-то определённый уровень. Например, уровень PANIC означает, что плохо стало всем, а уровень WARNING сообщает просто о подозрительных, но вполне законных событиях. В порядке возрастания подробности уровни имеют примерно следующую классификацию: PANIC, FATAL, LOG, ERROR, WARNING, NOTICE, INFO, DEBUG[1-5]. Уровень можно установить в процессе выполнения запроса. Следует осознавать, что журнал необходим при разбирательствах, но его активное использование ведёт к деградации производительности. Обычно эта уменьшение производительности находится в пределах 5% при условии, что журнальный файл расположен на другом диске нежели журнал транзакций.
** '''log_min_messages''' Характеризует уровень подробности записей в журнальный файл.
** '''log_error_verbosity''' Характеризует степень подробности делаемых в журнал записей. Различаются три степени: TERSE, DEFAULT и VERBOSE.
** '''client_min_messages''' Характеризует уровень подробности сообщений отсылаемых клиенту.
** '''log_min_error_statement''' Характеризует уровень подробностей записей в журнальный файл создаваемых в результате исполнения SQL-запросов.
* ''Что именно пишем в журнал (what to log)''
В этом разделе настроек перечислены различные возможные источники записей для журнала. Можно записывать информацию о делаемых соединениях (log_connections), информацию о выполняемых запросах (log_statement), информацию о времени уходящему на выполнение запросов (log_duration) и тому подобное. С помощью переменной log_line_preﬁx можно настроить идентификацию каждой записи по пользователю, IP, базе данных и так далее.

====Сбор статистики (Run-Time Statistics)====
Есть ложь, гнусная ложь и статистика. База данных врать не научена, поэтому остаётся только статистика. Этот раздел настроек отвечает за её сбор. Пока нет необходимости в мониторировании активности базы данных, нет необходимости здесь что-то править.

Для того чтобы работала автоматическая сборка мусора опции stats_start_collector и stats_row_level должны быть включены.

====Автоматическая сборка мусора (Automatic Vacuuming)====

Ну мусор, ну и пусть. Места много зачем напрягаться, да ещё автоматически?

В этом есть какая-то логика, но кроме сборки мусора (VACUUM) производится ещё и анализ (ANALYZE). Периодическое выполнение команды ANALYZE необходимо для нормального функционирования планировщика. Собранная с помощью этой команды статистика позволяет значительно ускорить выполнение SQL-запросов. То есть, если не хочется настраивать автоматическую сборку мусора, то в любом случае её придётся делать только теперь в ручную.

Процесс обычной сборки мусора в PostgreSQL (VACUUM без приставки FULL) не блокирует таблиц и может выполняться в фоне, не мешая выполнению запросов. Начиная с PostgreSQL версии 8.1 процесс автоматической сборки мусора выделяется в отдельный процесс. Эта группа настроек контролирует работу этого процесса.
* '''autovacuum''' Если Вы лучше чем PostgreSQL знаете когда следует производить сборку мусора, то автоматику можно выключить. Хотя лучше её просто правильно настроить. С другой стороны сборка мусора оттягивает на себя ресурсы системы и если это не допустимо, то её можно отложить на некоторое время. При настройке службы автоматической сборки мусора и анализа следует понимать, что один из зарезервированных с помощью superuser_reserved_connections слотов может оказаться в нужный момент занят.
* '''autovacuum_naptime''' Время в секундах через которое база данных проверяется на необходимость в сборке мусора. По умолчанию это происходит раз в минуту.
* '''autovacuum_vacuum_threshold''' Порог на число удалённых и изменённых записей в любой таблице по превышению которого происходит сборка мусора (VACUUM). По умолчанию этот порог равен 1000 и его вполне можно уменьшить.
* '''autovacuum_analyze_threshold''' Порог на число вставленных, удалённых и изменённых записей в любой таблице по превышению которого запускается процесс анализа (ANALYZE). По умолчанию это порог равен 500. Никто не запрещает сделать его поменьше.
* '''autovacuum_vacuum_scale_factor''' Процент изменённых и удалённых записей по отношению к таблице по превышению которого запускается сборка мусора. Значение по умолчанию равно 0.4.
* '''autovacuum_analyze_scale_factor''' То же, что и предыдущая переменная, но по отношению к анализу. Значение по молчанию равно 0.2.

====Настройки для пользователя по умолчанию (Client Connection Defaults)====

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

====Управление блокировками (Lock Management)====

Очевидно, что блокировок следует избегать всячески, причём делать это надо начинать на этапе проектирования базы данных. К сожалению реальная жизнь отличается от планов.
* '''deadlock_timeout''' Взаимные блокировки (deadlock) это чрезвычайно уродливое явление, при котором вошедшие в клинч процессы ожидают освобождение ресурсов, которые сами же и захватили. PostgreSQL умеет разрешать эту проблему путём насильного прерывания одного из процессов. Проверка на deadlock это довольно длительная процедура, поэтому, прежде чем начать проверку блокировки на предмет является ли она взаимной, сервер выжидает указанное время. Значение по умолчанию равно 1000 миллисекунд. Для загруженных серверов имеет смысл это значение увеличить.
* '''max_locks_per_transaction''' Вопреки своему названию это не жёсткий лимит на число блокировок, осуществляемых в пределах транзакций. Этот параметр входит в формулу устанавливающую предел на число одновременно существующих блокировок, то есть это скорее максимальное среднее: max_locks_per_transaction × (max_connections + max_prepared_transactions) В документации сказано, что 64 (число стоящее по умолчанию) это исторически проверенный предел и чтобы превзойти его требуются определённые усилия.

==О том, что думать тоже надо==
Можно идеально настроить сервер, регулярно проводить сборку мусора, можно закупить самое дорогое железо и поставить рядом с ним дизельную электростанцию. Но если таблицы и отношения между ними создавались без плана, а запросы задаются криво, то проблемы гарантировано будут.

Выполнение запросов следует проверять с помощью команды EXPLAIN ANALYZE, которая по полочкам разложит как ищется, сортируется, объединяется и группируется информация, какие для этого использовались алгоритмы и какие индексы были задействованы. Для любителей картинок pgAdmin III имеет графический интерфейс к этой команде. Ни в коем случае нельзя пренебрегать индексами и по возможности следует избегать блокировок.

===Настройки PostgreSQL для 1C===

По адресу http://v8.1c.ru/overview/postgres_patches_notes.htm лежат патчи. Это отличие версии сервера поставляемого с 1С:Предприятием 8 от оригинальных исходников PostgreSQL. Патч postgresql-1c-8.1.5.patch несёт в себеизменения в исходном файле настройки. Перечислим их:
* Допускаются сетевые соединения:
− i s t e n_a d d r e s s e s = ’ l o c a l h o s t ’
#l
+l i s t e n_a d d r e s s e s = ’ ∗ ’
* немного увеличен размер разделяемой памяти с 8 Мб до 28 Мб:
− h a r e d_b u f f e r s = 1000
#s
+s h a r e d_b u f f e r s = 3500
* оценка размера кэша системы изменилась с 8 Мб до 80 Мб:
− f f e c t i v e_ca che_s i z e = 1000
#e
+e f f e c t i v e_ca che_s i z e = 10000
* Включён процесс автоматической сборки мусора:
− t a t s_row_l e v e l = o f f
#s
+s t a t s_row_l e v e l = on
#autovacuum = o f f
−
+autovacuum = on
* Максимальное среднее число блокировок увеличено более чем в два раза:
#max_l o c k s_per_t r a n s a c t i o n = 64
−
+max_l o c k s_per_t r a n s a c t i o n = 150

Мне кажется, что судя по этим изменениям есть куда оптимизировать и сам продукт и настройки к PostgreSQL.

==Примечания==
<references />

LXF90:PostgreSQL

2008-03-13T11:35:54Z

PonElA:

LXF90:PostgreSQL

2008-03-13T11:35:27Z

PonElA: Новая: {{TOCright}} '''PostgreSQL. ЧАСТЬ 5: Настройка PostgreSQL''' PostgreSQL в фундаменте «1С:Предприятия»? В свое время эта новост...

{{TOCright}}
'''PostgreSQL. ЧАСТЬ 5: Настройка PostgreSQL'''

PostgreSQL в фундаменте «1С:Предприятия»? В свое время эта новость произвела фурор в мире Linux, а сегодня Евгений Балдин покажет, что для этого было сделано, и расскажет, как настроить PostgreSQL для выполнения этих или любых других задач

: - Между прочим, - сказал Роман громко, - уже в
:течение двух минут я пытаюсь его пассивизировать,
:и совершенно безрезультатно
::Понедельник начинается в субботу АБС
"Тюнинг" - это не операция - это образ жизни. Очевидно, что когда необходимые характеристики можно улучшить несколькими способами, то всеми способами их и надо улучшать. Но опять же следует помнить, что избыточная и ранняя оптимизация корень многих зол. Если система работает и не кашляет , то может быть не стоит её настраивать?

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

Как и для всякой программы, работающей с большим объёмом данных, дисковая подсистема является для PostgreSQL определяющей. Поэтому если есть возможность, то лучше вложиться именно в неё. В противоположность дисковой подсистеме процессор нагружается не очень сильно. Поэтому для сервера достаточно, чтобы процессор просто был, хотя лучше чтобы он был не один. Если денег на покупку хорошего SCSI диска нет, то следует вложиться в память.

К вопросу о дисках можно сказать, что чем их больше тем лучше. По возможности следует выделить отдельный диск для журнала транзакций (pg_xlog). Избыток дисков так же позволит собрать из них RAID. Хоть никто и не отменяет бэкапа, но дополнительная избыточность для дисковой подсистемы, как и источники бесперебойного питания, сэкономят массу сил и нервов.

Относительно недорогие системы снабжены дешёвыми встроенными RAID-контроллерами на четыре диска. Не следует использовать эти контроллеры, а лучше настроить софтверный RAID и не надо использовать RAID 5
<ref>
Один диск в массиве выделяется под контрольные суммы
</ref>
для небольшого числа дисков. До 6 дисков включительно лучше RAID 1+0
<ref>
зеркалирование (1) + объединение (0)
</ref>
. Избыточность во всём это только похоже на паранойю.

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

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

==Конфигурационные файлы==
Настройка конфигурационных файлов не единственный способ настройки сервера базы данных. Умолчания можно изменить непосредственно при сборке из исходников. Значения можно передавать непосредственно серверу postmaster в командной строке, используя ключик -с. Так же можно определить переменную окружения PGOPTIONS, а значения некоторых переменных можно изменить прямо в процессе выполнения запросов.

Концентрация внимания на конфигурационных файлах объясняется тем, что в любом случае их придётся настраивать. По умолчанию PostgreSQL сконфигурирован в расчёте на минимальное потребление ресурсов, и это не может не сказаться на скорости. Что подходит для локальной записной книжки не годится для боевого сервера.

Все настройки очень подробно описаны в документации. Для любителей выжимать из программы всё существует специальный список рассылки psql-performance: [http://archives.postgresql.org/pgsql-performance/ archives.postgresql.org]. В документации на странице Power PostgreSQL http://www.powerpostgresql.com/Docs также можно найти некоторое количество полезных подсказок.

Для настроек PostgreSQL используются файлы:
:'''pg_hba.conf''' - политика доступа и идентификации пользователей,
:'''postgresql.conf''' - собственно говоря, настройки сервера.

===pg_hba.conf===
Часто для локальных нужд при использовании PostgreSQL в качестве своей личной записной книжки, склада данных или даже помойки не требуется открывать сетевой доступ к базе данных. По умолчанию PostgreSQL настроен так, что каждый локальный пользователь может подсоединиться к базе совпадающей по названию с регистрационным именем клиента, при условии что такая база данных уже создана.

Но это не значит, что так бывает всегда. PostgreSQL предоставляет свои механизмы для управления пользователями с помощью тройки команд CREATE USER, DROP USER и ALTER USER. В случае не совпадающих регистрационных имен в PostgreSQL и в системе или при доступе к базе данных с других компьютеров необходимо обговорить правила доступа к данным на сервере.

Для настройки политики доступа к серверу волей-неволей придётся заглянуть в файл pg_hba.conf
<ref>
hba host-based authentication.
</ref>
. Тело файла представляют из себя однострочные записи, каждая из которых регулирует правила получения доступа для конкретной машины или для целой группы IP. Файл pg_hba.conf выглядит примерно следующим образом:

----
:Разрешаем доступ через локальные unix−сокеты абсолютно
:всем пользователям к базам данным, совпадающим по названию
:с регистрационными именами
local all all i d e n t sameuser
:Доверяем пользователю a l e x с указанного IP безгранично
:в рамках базы данных pho t o s
host pho t o s alex 130.255.204.48/32 trust
:Требуем пароль от пользователя b a l d i n при доступе с
:компьютеров из сети 1 2 8 . 1 3 8 . 2 4 2 . 1 9 2 / 2 7 к базам данных
:data и pho t o s
h o s t s s l data , pho t o s b a l d i n 1 2 8 . 1 3 8 . 2 4 2 . 1 9 2 / 2 7 md5
----

В файле по умолчанию присутствует подробная информация о формате записей,
первое поле которых определяет тип записи:
* local эта запись определяет политику для локального доступа через локальные UNIX-сокеты.
* host эта запись определяет политику для сетевого TCP/IP соединения и годится для соединений с использованием SSL и без него. Для того чтобы можно было доступаться к базе данных по сети необходимо правильно настроить listen_addresses в postgresql.conf.
* hostssl определяется политика для сетевого соединения с обязательным использованием SSL.
* hostnossl антипод hostssl.

Второе поле представляет из себя имя базы данных для которой определяется политика. Имя all зарезервировано для всех баз данных, а имя sameuser для базы данных, совпадающей с именем пользователя. Имена баз данных можно перечислять через запятую. Так же в качестве имени можно добавить имя файла со списком баз, разделённых запятой или пробелами. Для этого к имени файла следует добавить символ @ в качестве префикса.

Третье поле имя пользователя. Как и в случае имён баз данных можно работать со списками. Имя all зарезервировано для всех пользователей. Так же доступ можно открыть для группы пользователей (role), для этого перед именем группы следует поставить знак + .

Следующие ноль (в случае записи local), одно (нотация CIDR
<ref>
Classless Inter-Domain Routing
</ref>
) или два поля (адрес и сетевая маска) занимает сетевой адрес компьютера или подсети для которого настраивается политика доступа.

Предпоследнее обязательное поле отведено под метод авторизации:
* '''trust''' - полностью доверяем этому клиенту.
* '''reject''' - отказ в доступе.
* '''ident''' - доступ по регистрационной записи клиента. Часто применяется для локальных соединений. RFC 1413.
* '''md5''' - авторизация по паролю зашифрованному с помощью алгоритма md5. Если клиент использует библиотеку для доступа к PostgreSQL версии старше 7.2, то вместо метода md5 следует использовать метод crypt. Пароль при желании и значительной степени бесшабашности можно передавать открытым текстом с помощью метода password.
* '''pam''' - авторизация с помощью Pluggable Authentication Modules. Этот сервис предоставляется операционной системой. Подробнее о PAM написано здесь: http://www.kernel.org/pub/linux/libs/pam/.
* '''krb4 и krb5''' - авторизация с использованием механизма Kerberos версии 4 и 5, соответственно. Это индустриальный стандарт авторизации. То есть, кому надо тот знает что это такое.

После метода ему можно передать опции в последнем необязательном поле.

===postgresql.conf===

Настройки в postgresql.conf разбиты по группам и подробно задокументированы прямо в файле. Здесь будут описаны не все настройки, но важнейшие из них будут отмечены.

====Настройка соединений и авторизация (Connections and Authentication)====

Политика авторизации настраивается в pg_hba.conf. Здесь же собраны в основном технические параметры.
* ''Настройка соединений (connection settings'').
** '''listen_addresses''' После настройки pg_hba.conf можно и нужно смело устанавливать * слушаем все интерфейсы, которые есть в наличии. По умолчанию (localhost) запросы принимаются только от локальных пользователей в том числе и через интерфейс обратной связи (loopback-интерфейс 127.0.0.1).
** '''port''' Номер порта, который слушает сервер в ожидании соединений. По умолчанию он равен 5432.
** '''max_connections''' Число клиентов, которые могут подсоединяться к базе данных одновременно не может быть бесконечным. Каждое подсоединение порождает ещё один процесс postmaster, что, естественно, требует ресурсов. Средней паршивости современный однопроцессорный компьютер со стандартным наполнении без особых проблем может обслуживать 100-200 соединений, но, например, 600 активных соединений будут уже явной проблемой. Любая попытка подсоединиться сверх указанного лимита приведёт к отказу от обслуживания. Плохо написанная программа в цикле открывающая, но не закрывающая за собой оединения, легко создаст проблему. Если число клиентов жёстко ограничено, то имеет смысл уменьшить этот параметр до минимально возможного значения.
** '''superuser_reserved_connections''' Число соединений, которые зарезервированы для суперпользователя, чтобы он мог всегда зайти, разобраться в чём дело, а затем принять меры. Не стоит совсем отказываться зарезервированных соединений, причём одного зарезервированного соединения может оказаться не достаточно 2 это минимум.
* ''Безопасность и авторизация (security and authentication)''
** '''authentication_timeout''' Время ожидания для прохождения авторизации в секундах. По умолчанию это время равно одной минуте. Не позволяет клиенту зависнуть и заблокировать ресурс соединения на очень долгое время.
** '''ssl''' Разрешается доступ через ssl. Для работы через SSL необходимо создать публичный ключ и сертификат. Это требует некоторых усилий, зато позволяет немного успокоить себя на тему безопасности сетевых соединений.

====Управление ресурсами (Resource Consumption)====

Правильная оценка имеющихся ресурсов путь к эффективном планированию. А эффективное планирование позволяет в процессе работы не сильно увеличивать окружающую нас энтропию и в то же время добиваться поставленной цели. Очевидные истины.
* ''Память (memory)''
** '''shared_buﬀers''' Объём совместно используемой памяти, выделяемой PostgreSQL для кэширования данных, определяется числом страниц (shared_buﬀers) по 8 килобайт каждая. Естественно, данные умеет кэшировать не только сам PostgreSQL, но и операционная система сама по себе делает это очень неплохо. Поэтому нет необходимости отводить под кэш всю наличную оперативную память. Оптимальное число shared_buﬀers зависит от многих факторов, поэтому проще для начала принять следующие ориентиры:
*** Обычный настольный компьютер с 512 Мб и небольшой базой данных 8–16 Мб или 1000–2000 страниц.
*** Не сильно выдающийся сервер предназначенный для обслуживания базы данных с объёмом оперативной памяти 1 Гб и базой данных около 10 Гб 80–160 Мб или 10000–20000 страниц.
*** Сервер посерьёзнее с несколькими процессорами на борту, с объёмом памяти в 8 Гб и базой данных занимающей свыше 100 Гб обслуживающий несколько сотен активных соединений одновременно 400 Мб или 50000 страниц.
** '''work_mem''' Под каждый запрос можно выделить личный ограниченный объём памяти для работы. Этот объём может использоваться для сортировки, объединения и других подобных операций. При превышении этого объёма сервер начинает использовать временные файлы на диске, что может существенно замедлить скорость обработки запросов. Предел для work_mem можно вычислить, разделив объём доступной памяти (физическая память минус объём занятый под другие программы и под совместно используемые страницы shared_buﬀers) на максимальное число одновременно используемых активных соединений. При необходимости, например, выполнения очень объёмных операций, допустимый лимит можно изменять прямо во время выполнения запроса. Поэтому нет нужды изначально задавать теоретический предел.
** '''maintenance_work_mem''' Эта память используется для выполнения операций по сбору статистики (ANALYZE), сборке мусора (VACUUM), создания индексов (CREATE INDEX) и добавления внешних ключей. Рамер выделяемой под эти операции памяти должен быть сравним с физическим размером самого большого индекса на диске. Как и в случае work_mem эта переменная может быть установлена прямо во время выполнения запроса.
** '''max_prepared_transactions''' Определяет максимальное число подготовленных транзакций (команда PREPARE TRANSACTION). Подготовленные транзакции выполняются, но результат их не будет доступен пока их не подтвердят (COMMIT). Так же можно такие транзакции и отклонить (ROLLBACK). Если эта сущность нигде не используется, то переменную можно занулить.
* ''Карта неиспользованного пространства (free space map)'' При удалении записи не удаляются физически, а только помечаются как удалённые. Именно таким образом мусор и собирается.
** '''max_fsm_pages''' Для целей сборки мусора следует знать где этот мусор находится. Число страниц отведённых под эту задачу должно быть больше, чем число удалённых или изменённых записей между сборками мусора (VACUUM). Если страниц достаточно выполнение жёстких оптимизирующих операций, таких как VACUUM FULL или REINDEX никогда и не понадобится. Так как объём требуемой для этого памяти не очень большой (по 6 байт на страницу), то жадничать не стоит. Проще всего узнать необходимое число max_fsm_pages запустив, VACUUM VERBOSE ANALYZE.
** '''max_fsm_relations''' Число таблиц для которых создаются карты неиспользованного пространства. По умолчанию это число равно 1000. В случае большего числа используемых таблиц это значение можно и нужно увеличить, тем более что на каждую таблицу требуется всего по семь байт.
* ''Системные ресурсы (kernel resource usage)''
** '''preload_libraries''' Если для исполнения запроса требуется загрузить какую-либо разделяемую библиотеку, то действует правило: загружаем при первом использовании , что замедляет исполнение самого первого такого запроса. Это можно обойти, загрузив необходимые библиотеке при старте сервера, то есть воспользоваться формулой: память в обмен на скорость. Таким образом можно подгрузить разделяемую библиотеку для используемых в запросах процедурных языков.
* ''Оценка стоимости сборки мусора (cost-based vacuum delay)'' Немного подробнее про сборку мусора будет рассказываться далее. Обычно нет необходимости заглядывать в этот раздел, так как сборка мусора (VACUUM) и анализ (ANALYZE) выполняются достаточно быстро.
* ''Запись в фоне (background writer)''

Начиная с версии PostgreSQL 8.0 вместе с основным сервером стартует процесс для записи данных в фоне. При выполнении запроса нет необходимости ждать самого акта записи, так как это гарантировано сделает background writer.

====Журнал транзакций (Write Ahead Log)====

Наличие журнала транзакций или WAL (write ahead log) позволяет увеличить скорость выполнения операций требующих изменения данных в следствии того, что в журнал информация об изменениях пишется последовательно, а изменения в самих таблицах могут быть отложены до лучших времён своеобразный кэш только на диске. Если же база данных используется в основном для чтения, то в журнале транзакций нет особой необходимости, но это не повод от него отказываться.
* ''Настройки (settings)''
** '''fsync''' По умолчанию эта опция включена (true). В этом случае PostgreSQL пытается записать данные на диск физически. Это на самом деле не такая уж и простая операции, так как кэши существуют не только в системе, но и в контроллерах и в дисках. Вполне можно представить себе такую ситуацию, что слишком умный диск для увеличения своей производительности в тестах рапортует о том, что данные записаны, а при перебое с электричеством выясняется, что это была просто шутка. Сбои самого сервера не приводят к порчи данных, но сервер живёт в окружении далеко не идеальной операционной системе, которая в свою очередь управляет далеко не идеальными физическими устройствами. Так что проверенное железо, источники бесперебойного питания, бэкап, бэкап и ещё раз бэкап.<br/>
Если Вы доверяете своему железу, то эту опцию можно выключить. Здесь можно поменять немного безопасности на скорость. Хотя более оптимальным решением является перенос журнального файла на отдельный быстрый диск. То есть прикупить скорость за деньги.
* ''Контрольные точки (checkpoints)'' По свершению каких-то определённых условий или истечению контрольного времени сервер гарантировано переносит данные, записанные в WAL непосредственно в таблицы, даже если очень сильно занят на других запросах.
** '''checkpoint_segments''' Объём кэша на диске. Физический объём места на диске, требуемый под кэш вычисляется по формуле (checkpoint_segments × 2 + 1) × 16 Мб. Следует выделить столько, сколько не жалко, осознавая, что 32 сегмента займёт на диске свыше 1 Гб.
** '''checkpoint_timeout''' Время, через которое WAL очищается насильно. По умолчанию 300 секунд.
** '''checkpoint_warning''' Если кэш а диске заполняется быстрее чем число секунд checkpoint_warning, то посылается предупреждение, которое будет передано в журнальный файл. Это намёк, что кэш на диске следует увеличить.
* ''Архивация (archiving)''
** '''archive_command''' Для целей создания непрерывного резервного копирования (возможность для настоящих параноиков) журнал необходимо копировать куда-то ещё. Здесь должна быть команда, которая будет использоваться системой для копирования данных. Подробности следует искать в документации в разделе On-line backup and point-in-time recovery (PITR).

====Планирование запросов (Query Planning)====

Здесь можно повлиять на логику действия планировщика. Возможно конкретно для Вашей системы значения по умолчанию не оптимальны, но менять их стоит только после серии тестов для выявления более оптимальной конфигурации под конкретную платформу и конкретные запросы. В большинстве случаев углубляться в тонкости настроек из этого раздела имеет смысл только в случае очень изощрённых запросов.
* Методология планировщика (planner method conﬁguration) В этом разделе перечислены алгоритмы, которые можно использовать для извлечения данных. Для целей тестирования какие-то из них можно отключить.
* Оценочные константы (planner cost constants)
** '''eﬀective_cache_size''' PostgreSQL в своих планах опирается на кэширование файлов, осуществляемое операционной системой. Этот параметр соответствует максимальному размеру объекта, который может поместиться в системный кэш. Установка этого параметра не приводит к увеличению выделяемой памяти. Это значение используется только для оценки. eﬀective_cache_size можно установить в 1/3 от объёма имеющейся в наличии оперативной памяти, если вся она отдана в распоряжение PostgreSQL.

====Сообщения об ошибках и событиях (Error Reporting and Logging)====

Оптимизация возможно только в случае обратной связи. Сервер PostgreSQL может много чего про себя рассказать. Этот раздел настроек посвящён тому, как правильно его об этом попросить.
* ''Местоположение журнального файла (where to log)''
** '''log_destination''' Здесь можно выбрать способ записи в журнальный файл: stderr или syslog. Метод stderr хорош для тестирования, но по хорошему журналированием должна заниматься специальная служба, а это нас приводит к необходимости изучить что такое syslog. В случае выбора метода stderr придётся определить директорию для журнального файла (log_directory), имя журнального файла (log_ﬁlename) и другие параметры (log_rotation_age, log_rotation_size, log_truncate_on_rotation) свойственный службе журналирования. В случае выбора метода syslog настроить его с помощью syslog_facility (необходимо знать как пользоваться syslog) и syslog_iden идентификационный префикс для сообщений получаемых от PostgreSQL.
* ''По какому случаю создаём запись (when to log)'' Обычно, нет необходимости записывать в дневник информацию о каждом чихе, но при серьёзном разбирательстве данные о числе чихов в секунду и их классификация могут подтолкнуть в нужном направлении. Каждому событию можно присвоить какой-то определённый уровень. Например, уровень PANIC означает, что плохо стало всем, а уровень WARNING сообщает просто о подозрительных, но вполне законных событиях. В порядке возрастания подробности уровни имеют примерно следующую классификацию: PANIC, FATAL, LOG, ERROR, WARNING, NOTICE, INFO, DEBUG[1-5]. Уровень можно установить в процессе выполнения запроса. Следует осознавать, что журнал необходим при разбирательствах, но его активное использование ведёт к деградации производительности. Обычно эта уменьшение производительности находится в пределах 5% при условии, что журнальный файл расположен на другом диске нежели журнал транзакций.
** '''log_min_messages''' Характеризует уровень подробности записей в журнальный файл.
** '''log_error_verbosity''' Характеризует степень подробности делаемых в журнал записей. Различаются три степени: TERSE, DEFAULT и VERBOSE.
** '''client_min_messages''' Характеризует уровень подробности сообщений отсылаемых клиенту.
** '''log_min_error_statement''' Характеризует уровень подробностей записей в журнальный файл создаваемых в результате исполнения SQL-запросов.
* ''Что именно пишем в журнал (what to log)''
В этом разделе настроек перечислены различные возможные источники записей для журнала. Можно записывать информацию о делаемых соединениях (log_connections), информацию о выполняемых запросах (log_statement), информацию о времени уходящему на выполнение запросов (log_duration) и тому подобное. С помощью переменной log_line_preﬁx можно настроить идентификацию каждой записи по пользователю, IP, базе данных и так далее.

====Сбор статистики (Run-Time Statistics)====
Есть ложь, гнусная ложь и статистика. База данных врать не научена, поэтому остаётся только статистика. Этот раздел настроек отвечает за её сбор. Пока нет необходимости в мониторировании активности базы данных, нет необходимости здесь что-то править.

Для того чтобы работала автоматическая сборка мусора опции stats_start_collector и stats_row_level должны быть включены.

====Автоматическая сборка мусора (Automatic Vacuuming)====

Ну мусор, ну и пусть. Места много зачем напрягаться, да ещё автоматически?

В этом есть какая-то логика, но кроме сборки мусора (VACUUM) производится ещё и анализ (ANALYZE). Периодическое выполнение команды ANALYZE необходимо для нормального функционирования планировщика. Собранная с помощью этой команды статистика позволяет значительно ускорить выполнение SQL-запросов. То есть, если не хочется настраивать автоматическую сборку мусора, то в любом случае её придётся делать только теперь в ручную.

Процесс обычной сборки мусора в PostgreSQL (VACUUM без приставки FULL) не блокирует таблиц и может выполняться в фоне, не мешая выполнению запросов. Начиная с PostgreSQL версии 8.1 процесс автоматической сборки мусора выделяется в отдельный процесс. Эта группа настроек контролирует работу этого процесса.
* '''autovacuum''' Если Вы лучше чем PostgreSQL знаете когда следует производить сборку мусора, то автоматику можно выключить. Хотя лучше её просто правильно настроить. С другой стороны сборка мусора оттягивает на себя ресурсы системы и если это не допустимо, то её можно отложить на некоторое время. При настройке службы автоматической сборки мусора и анализа следует понимать, что один из зарезервированных с помощью superuser_reserved_connections слотов может оказаться в нужный момент занят.
* '''autovacuum_naptime''' Время в секундах через которое база данных проверяется на необходимость в сборке мусора. По умолчанию это происходит раз в минуту.
* '''autovacuum_vacuum_threshold''' Порог на число удалённых и изменённых записей в любой таблице по превышению которого происходит сборка мусора (VACUUM). По умолчанию этот порог равен 1000 и его вполне можно уменьшить.
* '''autovacuum_analyze_threshold''' Порог на число вставленных, удалённых и изменённых записей в любой таблице по превышению которого запускается процесс анализа (ANALYZE). По умолчанию это порог равен 500. Никто не запрещает сделать его поменьше.
* '''autovacuum_vacuum_scale_factor''' Процент изменённых и удалённых записей по отношению к таблице по превышению которого запускается сборка мусора. Значение по умолчанию равно 0.4.
* '''autovacuum_analyze_scale_factor''' То же, что и предыдущая переменная, но по отношению к анализу. Значение по молчанию равно 0.2.

====Настройки для пользователя по умолчанию (Client Connection Defaults)====

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

====Управление блокировками (Lock Management)====

Очевидно, что блокировок следует избегать всячески, причём делать это надо начинать на этапе проектирования базы данных. К сожалению реальная жизнь отличается от планов.
* '''deadlock_timeout''' Взаимные блокировки (deadlock) это чрезвычайно уродливое явление, при котором вошедшие в клинч процессы ожидают освобождение ресурсов, которые сами же и захватили. PostgreSQL умеет разрешать эту проблему путём насильного прерывания одного из процессов. Проверка на deadlock это довольно длительная процедура, поэтому, прежде чем начать проверку блокировки на предмет является ли она взаимной, сервер выжидает указанное время. Значение по умолчанию равно 1000 миллисекунд. Для загруженных серверов имеет смысл это значение увеличить.
* '''max_locks_per_transaction''' Вопреки своему названию это не жёсткий лимит на число блокировок, осуществляемых в пределах транзакций. Этот параметр входит в формулу устанавливающую предел на число одновременно существующих блокировок, то есть это скорее максимальное среднее: max_locks_per_transaction × (max_connections + max_prepared_transactions) В документации сказано, что 64 (число стоящее по умолчанию) это исторически проверенный предел и чтобы превзойти его требуются определённые усилия.

==О том, что думать тоже надо==
Можно идеально настроить сервер, регулярно проводить сборку мусора, можно закупить самое дорогое железо и поставить рядом с ним дизельную электростанцию. Но если таблицы и отношения между ними создавались без плана, а запросы задаются криво, то проблемы гарантировано будут.

Выполнение запросов следует проверять с помощью команды EXPLAIN ANALYZE, которая по полочкам разложит как ищется, сортируется, объединяется и группируется информация, какие для этого использовались алгоритмы и какие индексы были задействованы. Для любителей картинок pgAdmin III имеет графический интерфейс к этой команде. Ни в коем случае нельзя пренебрегать индексами и по возможности следует избегать блокировок.

===Настройки PostgreSQL для 1C===

По адресу http://v8.1c.ru/overview/postgres_patches_notes.htm лежат патчи. Это отличие версии сервера поставляемого с 1С:Предприятием 8 от оригинальных исходников PostgreSQL. Патч postgresql-1c-8.1.5.patch несёт в себеизменения в исходном файле настройки. Перечислим их:
* Допускаются сетевые соединения:
− i s t e n_a d d r e s s e s = ’ l o c a l h o s t ’
#l
+l i s t e n_a d d r e s s e s = ’ ∗ ’
* немного увеличен размер разделяемой памяти с 8 Мб до 28 Мб:
− h a r e d_b u f f e r s = 1000
#s
+s h a r e d_b u f f e r s = 3500
* оценка размера кэша системы изменилась с 8 Мб до 80 Мб:
− f f e c t i v e_ca che_s i z e = 1000
#e
+e f f e c t i v e_ca che_s i z e = 10000
* Включён процесс автоматической сборки мусора:
− t a t s_row_l e v e l = o f f
#s
+s t a t s_row_l e v e l = on
#autovacuum = o f f
−
+autovacuum = on
* Максимальное среднее число блокировок увеличено более чем в два раза:
#max_l o c k s_per_t r a n s a c t i o n = 64
−
+max_l o c k s_per_t r a n s a c t i o n = 150

Мне кажется, что судя по этим изменениям есть куда оптимизировать и сам продукт и настройки к PostgreSQL.

==Примечания==
<references />'''Полужирное начертание'''

Обсуждение:Добро пожаловать!

2008-03-13T06:41:36Z

PonElA:

Не хватает журнала №71
:И еще № 87-88

LXF89:PostgreSQL

2008-03-12T12:40:12Z

PonElA: /* Открытие и закрытие соединения */

'''PostgreSQL. ЧАСТЬ 4: Интерфейсы'''

:В институте им очень дорожили, так как
:попутно он использовался для некоторых
:уникальных экспериментов и как переводчик
:при общении со Змеем Горынычем.
::АБС о Кощее Бессмертном

==libpq==
Чтобы общаться с базой данных много функций не надо: одна функция для открытия соединения, одна для посылки запроса, одна для получения ответа и одна для закрытия соединения. В реальности всё немного сложнее, но суть остаётся.

К вопросу о переносимости Библиотека libpq написана на чистом C, поэтому практически везде, где есть gcc, можно организовать связь с PostgreSQL. Мне както пришлось это делать для VAX/VMS всё решилось методом тыка, даже думать почти не потребовалось. Все данные текст, поэтому вопрос бинарной совместимости платформ попросту отсутствует.

С чего начать Для того чтобы воспользоваться вызовами libpq, необходимо для начала установить её. В Debian (Etch) для этого надо установить пакет postgresql-dev:
> sudo apt−g e t i n s t a l l p o s t g r e s q l −dev
Для доступа к функциям libpq необходимо включить в исходник include-файл:
#include "libpq−f e . h"

Скрипт pg_conﬁg (man pg_conﬁg) позволяет получить информацию куда помещаются include-файлы, библиотеки и тому подобное:
> #сборка программы
> g cc −o "бинарник" "исходник" . c −I ‘ pg _ co nf i g −−i n c l u d e d i r ‘ \
−l p q ‘ pg _ co nf i g −−l i b s ‘

===Открытие и закрытие соединения===

Даже открывать соединение с PostgreSQL можно двумя способами:
// открыть соединение
PGconn ∗ PQconnectdb ( const char ∗ c o n n i n f o ) ;
// то же , но не блокируя программу
PGconn ∗ PQconnectStart ( const char ∗ c o n n i n f o ) ;
// проверка ст а т уса соединения ( после PQconnectStart )
P o s t g r e s P o l l i n g S t a t u s T y p e PQconnectPoll ( PGconn ∗ conn ) ;
PQconnectdb обычная функция, где на вход подаём текстовую строку conninfo с параметрами для соединения с сервером, а на выходе получаем структуру типа PGconn с информацией о сделанном соединении и на сколько операция по соединению прошла удачно. В дальнейшем при передача данных эта переменная будет использоваться в качестве параметра.

Передача информации о серевере в качестве строки (conninfo) позволяет в случае появления дополнительных параметров не менять внешний интерфейс вызова и легко добавлять дополнительные опции. Пример открытия соединения:
const char ∗ c o n n i n f o= "dbname = t est host=lo c alho st " ;
PGconn ∗ conn=PQconnectdb ( c o n n i n f o ) ;
i f ( PQstatus ( conn ) != CONNECTION_OK) {
f p r i n t f ( s t d e r r , "Не удалось соединиться с базой данных: %s" ,
PQerrorMessage ( conn ) ) ;
/∗ завершаем работу ∗/ . . . }
Параметры передаются в форме ключевое слово = значение. Пары разделяются обычным пробелом. Пробелы вокруг знака равенства можно опустить. Если необходимо передать значение с пробелами, то его необходимо заключить в одинарные кавычки ’ составное значение ’. Для передачи одинарной кавычки её необходимо экранировать с помощью обратной косой черты \’. При отсутствии какого-либо параметра в строке conninfo его значение берётся из соответствующей переменной окружения, если такая определена. Если нет, то при открытии соединения используется значение по умолчанию.

Функции открытия соединения распознают следующие параметры и переменные окружения (кое-какие особенности опущены):
* '''host TCP/IP''' имя узла на котором находится сервер PostgreSQL. Соответствует переменной окружения PGHOST. Значение по умолчанию localhost.
* '''hostaddr''' Числовой адрес узла на котором находится PostgreSQL (альтернатива host). Соответствует переменной окружения PGHOSTADDR. Значение по умолчанию эквивалентно localhost.
* '''port''' Номер порта, который слушает POSTMASTER. Соответствует переменной окружения PGPORT. Значение по умолчанию обычно 5432.
* '''dbname''' Имя базы данных. Соответствует переменной окружения PGDATABASE. Значение по умолчанию совпадает с системной учётной записью пользователя.
* '''user''' Имя пользователя базы данных. Соответствует переменной окружения PGUSER. Значение по умолчанию совпадает с системной учётной записью пользователя.
* '''password''' Поле пароля, если для аутентификации требуется пароль. Соответствует переменной окружения PGPASSWORD. Если аутентификация требуется, а поле неопределенно, то для доступа используется информация в файле ~/.pgpass. Переменная окружения PGPASSFILE может указать другой файл для проведения аутентификации.
* '''connect_timeout''' Устанавливает максимальное время ожидания соединения в секундах. С сервером и сетью всякое может случиться. Соответствует переменной окружения PGCONNECT_TIMEOUT. Значение по умолчанию равно 0, что означает что время ожидания равно бесконечности. Не рекомендуется устанавливать значение на ожидание меньше 2 секунд.
* '''options''' Опции, посылаемые непосредственно серверу, коли такое потребуется. Соответствует переменной окружения PGOPTIONS.
* '''sslmode''' Определяет порядок действий при SSL-соединении. Принимает четыре возможных значения:
** '''disable''' без шифрации,
** '''allow''' сначала попробовать соединиться без шифрации, а в случае неудачи постараться установить защищённое соединение,
** '''prefer''' сначала попробовать установить защищённое соединения, а в случае неудачи повторить соединение без шифрации,
** '''require''' выполнять только защищённое соединение.

Соответствует переменной окружения PGSSLMODE. Значение по умолчанию prefer.
* '''krbsrvname''' Имя Kerberos-сервиса. используется для аутентификации с помощью Kerberos-5<ref>
Kerberos промышленный стандарт для аутентификации и взаимодействия в условиях незащищённого окружения. Алгоритмы Kerberos основаны на шифровании с использованием симметричного криптографического ключа и требует наличие доверенного агента.
</ref>. Это совершенно отдельная тема для беседы. Соответствует переменной окружения PGKRBSRVNAME.

PGDATESTYLE Переменная окружения, позволяющая установить представление времени и даты по умолчанию. Соответствует SQL-команде SET datestyle TO. . .
PGTZ Переменная окружения, позволяющая установить текущий часовой пояс. Соответствует SQL-команде SET timezone TO. . .
PGCLIENTENCODING Переменная окружения, позволяющая установить кодировку клиента. Соответствует SQL-команде SET client_encoding TO. . .

Существует целый класс функций, которые позволяют получить информацию о соединении. Для подробностей следует обратиться к документации. Для начала полезно знать о двух из них:
ConnStatusType PQstatus ( const PGconn ∗ conn ) ;
char ∗ PQerrorMessage ( const PGconn ∗ conn ) ;
PQstatus возвращает информацию о том, как прошло соединение. Интересны состояния CONNECTION_OK всё хорошо и CONNECTION_BAD ничего не вышло. Функция PQerrorMessage позволяет получить текстовую строку с описанием последней возникшей проблемы.

Для того чтобы разорвать соединение используется функция:
void P Q f i n i s h ( PGconn ∗ conn ) ;

ВНИМАНИЕ! Всегда следует закрывать соединения, когда в них отпадает нужда.

Число соединений которые поддерживает POSTMASTER ограничено очень легко парализовать работу базы данных только открывая новые соединения.

===SQL запросы===
Что ж, до сервера уже дозвонились , теперь пора с ним поговорить.

'''Посылка запросов''' Простейший способ выполнить SQL-запрос, это воспользоваться функцией PQexec:
PG r esul t ∗PQexec ( PGconn ∗ conn , const char ∗command ) ;
В качестве параметров передаётся структура соединения conn и строка с SQL-командой command. Возвращается указатель на структуру типа PGresult, где сохраняется информация полученная от СУБД в ответ на запрос. При желании можно в одном запросе отсылать сразу несколько SQL-команд, разделённых точкой с запятой ; , но в этом случае информация сохранённая в структуре PGresult будет относиться только к последнему запросу.

По умолчанию каждый PQexec считается за отдельную транзакцию, если явно не начать транзакцию с помощью команды BEGIN, которая будет продолжаться либо до COMMIT, либо до ROLLBACK.

Есть более сложный вызов PQexecParams, который позволяет передавать вызов и параметры к этому вызову раздельно. Таким образом исчезает необходимость самостоятельно формировать строку SQL-команды и заботиться об экранировании данных, что важно в случае сохранения бинарных последовательностей. В качестве платы из соображения безопасности PQexecParams может послать не более одной команды за раз.

В некоторых случаях для увеличения скорости выполнения часто встречающихся запросов полезно обратить внимание на парочку PQprepare и PQexecPrepared. Эти команды эквивалентны своим SQL-аналогам PREPARE и EXECUTE. Идея оптимизации состоит в том, что прежде чем выполнить запрос, PostgreSQL сначала анализирует его, затем планирует порядок действий и только потом, собственно, выполняет запрос. Первые два этапа для похожих запросов с разными условиями отбора можно выполнить заранее с помощью команды PREPARE. Затем, с помощью команды EXECUTE, можно выполнять подобные уже подготовленные (prepared)
запросы.

Все упомянутые выше команды работают с сервером БД синхронным образом, то есть посылают запрос и ждут ответа. Клиентское приложение на это время засыпает (suspended). В libpq предусмотрен целый класс функций предназначенный для асинхронных операций, не блокирующих клиентское приложение. Их применение усложняет код и логику программы, хотя всё в пределах допустимого. С моей точки зрения лучше организовать всё так, чтобы время использованное на ожидание результатов запроса фатально не влияло на внешние процессы и обеспечить бесперебойную работу сети и сервера базы данных.

'''Информация о состоянии запроса''' После выполнения запроса всегда интересно узнать каково его состояние:
ExecStatusType P Q r e s u l t S t a t u s ( const PG r esul t ∗ r e s ) ;
На вход подаётся структура PGresult, создаваемая в результате работы PQexec подобных функций, а на выходе получаем информацию о состоянии в виде числа, значение которого можно сравнить со следующими константами:
PGRES_COMMAND_OK всё прошло хорошо (для запросов, которые не возвращают данные, например, INSERT),
PGRES_TUPLES_OK всё прошло хорошо, плюс получены данные в ответ на запрос (для запросов типа SELECT или SHOW),
PGRES_EMPTY_QUERY строка запроса была почему-то пустой,
PGRES_COPY_OUT идёт передача данных от сервера,
PGRES_COPY_IN идёт передача данных на сервер,
PGRES_BAD_RESPONSE ошибка, ответ сервера не разборчив,
PGRES_NONFATAL_ERROR ошибка, не смертельно: предупреждение (notice) или информация к сведению (warning),
PGRES_FATAL_ERROR при выполнении запроса произошла серьёзная ошибка.

Для получения более подробной информации об ошибке следует воспользоваться функцией
char ∗ PQ r esul t Er r o r Messa g e ( const PG r esul t ∗ r e s ) ;
При вызове этой функции в качестве результата будет сформирована строка с информацией об ошибке или пустая строка если всё прошло хорошо.

'''Получение данных''' При получении данных предполагается, что статус запроса соответствует PGRES_TUPLES_OK. Теперь, если примерно известно что хочется получить в результате запроса, то для получения данных достаточно четырёх функций:
int PQntuples ( const PG r esul t ∗ r e s ) ;
int P Q n f i e l d s ( const PG r esul t ∗ r e s ) ;
char ∗ PQgetvalue ( const PG r esul t ∗ r e s ,
int row_number , int column_number ) ;
int P Q g e t i s n u l l ( const PG r esul t ∗ r e s ,
int row_number , int column_number ) ;
Первые две функции являются информационными и позволяют узнать сколько в результате запроса получено строк (PQntuples) и сколько колонок в каждой такой строке (PQnﬁelds). Возьмите на заметку, что 0 строк это тоже хороший результат.

Функция PQgetvalue позволяет получить доступ к полученным данным. В качестве параметров кроме структуры соединения (res) передаётся номер строки (column_number) и номер колонки (column_number). Все данные возвращаются так же в виде текстовой строки, как и посылаются, то есть, эти данные необходимо перевести в привычный формат. Например, в случае целых чисел можно восполь-
зоваться функцией atoi.

Следует помнить, что данные SQL могут иметь неопределённое значение (NULL). Если подобная возможность существует, то перед получением значения проверить, а определено ли оно. PQgetisnull позволяет разобраться с этой проблемой. По передаваемым параметрам эта функция эквивалентна PQgetvalue, а в качестве результата возвращает 1, если значение не определено и 0, если опеределено.

Кроме упомянутых существует целый ряд функций, позволяющих получить информацию о полученных данных, как то: имя колонки (PQfname), размер передаваемых данных в байтах (PQgetlength) и тому подобное. Для экранирования специальных символов при операции с бинарными или текстовыми данными есть набор сервисных функций PQescape∗.

'''COPY''' SQL команда COPY является расширением специфичным для PostgreSQL.

Основное преимущество SQL всё есть понятный текст, в некоторых случаях, когда надо передавать большие объёмы данных, оборачивается недостатком.
Функции PQputCopyData и PQgetCopyData позволяют под час значительно ускорить передачу данных между сервером и клиентом.

'''Асинхронные сигналы''' Стандартный SQL не предполагает взаимодействия разных пользователей, кроме как через изменение данных в таблицах. PostgreSQL позволяет посылать асинхронные сигналы с помощью команд LISTEN и NOTIFY. LISTEN "имя сигнала" передаётся серверу как обычная SQL-команда. Если статус запроса становится равным PGRES_COMMAND_OK, то это означает, что ранее был выполнен запрос NOTIFY "имя сигнала". Если же инициализация сигнала (NOTIFY) ожидается позже регистрации (LISTEN), то функция PQnotiﬁes позволяет после любого запроса проверить наличие сигнала вновь.

'''Сборка мусора''' Мусор убирать придётся руками. Каждая функция типа PQexec создаёт объект типа PGresult. После того как вся необходимая информация о результатах запроса получена, следует освободить память, занимаемую этим объектом с помощью команды:
void PQclear ( PG r esul t ∗ r e s ) ;
Если утечки памяти Вас не волнуют, то можно этого и не делать. В этом случае следует побеспокоиться о том: Почему Вас не беспокоят утечки памяти?

===Большие объекты===
Ещё один способ сохранять неструктурированные данные в PostgreSQL это пихать их как большие объекты (Large Objects). PostgreSQL предоставляет интерфейс схожим с файловым интерфейсом Unix: open (lo_open), read (lo_read), write (lo_write), lseek (lo_lseek) и так далее. Все lo_∗ команды работают со значениями полученными из колонки с типом oid. oid это специальный тип данных, который является ссылкой на объект произвольного типа. То есть последовательность работы с большим объектом следующая: создаётся большой объект (lo_create). Далее возвращаемый lo_create указатель Oid используется для записи данных в большой объект (lo_import/lo_write), а затем этот указатель вставляется в таблицу с помощью стандартных SQL операторов. Чтение происходит в обратном порядке (lo_export/lo_read). Все операции с большими объектами должны происходить внутри транзакции.

'''P.S.''' Необходимость интерфейса больших объектов на текущий момент не так уж и очевидна. Стандартными средствами в PostgreSQL можно сохранять бинарные данные размером вплоть до 1 Гб, что вполне может соперничать с максимальным размером для большого объекта в 2 Гб.

==ECPG==
Чтобы не отставать от коммерческих баз данных PostgreSQL имеет свой собственный вариант встроенного SQL . Эта технология позволяет смешивать обычный язык C с SQL-структурами, примерно следующим образом:

// файл test.pgc
#include <stdio.h>
#include <stdlib.h>
// структура для обработки ошибок
EXEC SQL i n c l u d e s q l c a ;
// реакция в случае ошибки/ предупреждения
EXEC SQL whenever s q l w a r n i n g s q l p r i n t ;
EXEC SQL whenever s q l e r r o r do E x i t F o r E r r o r ( ) ;
void E x i t F o r E r r o r ( ) {
f p r i n t f ( s t d e r r , "Всё , конец − это фатально .\n" ) ;
sqlprint ();
exit (1);
}
int main ( int argc , char ∗∗ argv )
{
// определение переменных , чтобы их можно было использовать
// инструкциях ECPG
EXEC SQL BEGIN DECLARE SECTION;
const char ∗dbname = " t est " ;
const char ∗ u s e r = "baldin" ;
VARCHAR FIO [ 1 2 8 ] ;
VARCHAR NUMBER[ 1 2 8 ] ;
EXEC SQL END DECLARE SECTION ;
// соединение с базой данных
// внешние переменные предваряются двоеточием
EXEC SQL CONNECT TO : dbname USER : u s e r ;
// определение курсора через SELECT
EXEC SQL DECLARE mycursor CURSOR FOR
SELECT f i o , number FROM f i o d a t a , phonedata
WHERE f i o d a t a . i d=phonedata . i d ;
EXEC SQL open mycursor ;
// чтение данных из курсора
EXEC SQL FETCH NEXT FROM mycursor INTO : FIO , :NUMBER;
while ( s q l c a . s q l c o d e == 0 ) { // не 0 , если данные больше нет
p r i n t f ( " И %s номер : %s\n" , FIO . a r r ,NUMBER. a r r ) ;
Ф О:
EXEC SQL FETCH NEXT FROM mycursor INTO : FIO , :NUMBER;
}
// разъединение с базой данных
EXEC SQL DISCONNECT;
}

Все SQL-команды начинаются с метки EXEC SQL. Эта метка позволяет затем препроцессору ecpg обработать и произвести C-исходник. Внутри SQL-команд можно использовать C-переменные. Для этого переменным в начале добавляется двоеточие : .

Для компиляции выше процитированного исходника (файл test1.pgc) необходимо выполнить следующие действия:
> # установить ecpg
> sudo apt−g e t i n s t a l l l i b e c p g −dev
> # запустить препроцессор
> ecpg t e s t 1 . pgc
> # скомпилировать получившийся исходник
> g cc −o t e s t 1 t e s t 1 . c −I ‘ pg _ co nf i g −−i n c l u d e d i r ‘ −l e c p g
> # проверка работоспособности программы
> ./ test1
ФИО: Иванов И.П. номер : 555−32−23
ФИО: Балдин Е .М. номер : 555−41−37
ФИО: Балдин Е .М. номер : (+7)5559323919

Удобно это или нет решайте сами.

==Всё остальное==
Статья называется Интерфейсы , а большая часть посвящена только одному из них. Дело в том, что этот один является родным и наиболее полным, а всё остальное лишь подмножество. В простейшем случае все интерфейсы одинаковы: открыл соединение, послал запрос, обработал результаты запроса, закрыл соединение. Так же заметна энергосберегающая тенденция везде делать ровно один интерфейс на все типы СУБД.

* '''bash''' Да, да к bash тоже есть свой интерфейс, правда для этого надо патчить его исходники. Возни, конечно, не мало зато прямо в shell-скриптах можно обращать к базе данных. [http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html Страничка проекта].

* '''Java''' Совершенно ожидаемо, что Java общается с PostgreSQL стандартным образом, а именно через JDBC. Поэтому если знаком с Java, то достаточно добыть драйвер JDBC для PostgreSQL, например [http://jdbc.postgresql.org/ отсюда] или в Debian (Sarge) набрать
> sudo apt−g e t i n s t a l l l i b p g j a v a
и, прочитав README к пакету, приступить к работе.

* '''lisp''' Точнее Common Lisp. Скорее всего эти драйвера подойдут и для других диалектов:
> sudo apt−g e t i n s t a l l c l −pg
#или
> sudo apt−g e t i n s t a l l c l −s q l −p o s t g r e s q l
Второй вариант является драйвером для единого интерфейса доступа к SQL-базам данных из Common Lisp [http://clsql.b9.com/ CLSQL].

* '''perl''' Интерфейс для связи с PostgreSQL DBD-Pg используется в perl через DBI<ref>DBI унифицированный интерфейс для доступа к данным. Подробнее об этом пакете можно посмотреть на CTAN: http://search.cpan.org/~timb/DBI-1.52/DBI.pm</ref>. Все подробности на [http://search.cpan.org/~dbdpg/DBD-Pg/Pg.pm CTAN].
> l i bdbd −pg−p e r l
DBD-Pg охватывает фактически все имеющиеся на сегодня возможности PostgreSQL от больших объектов (large objects), до точек сохранения (savepoints).

* '''PHP''' О том как использовать PostgreSQL в PHP-проектах можно прочитать [http://www.php.net/manual/en/ref.pgsql.php здесь]. Установить драйвер можно, например, так:
> sudo apt−g e t i n s t a l l php5−p g s q l
Говорят, почти единственной причиной, по которой PHP-разработчики предпочитают MySQL является то, что раньше не было родной версии PostgreSQL под альтернативную операционную систему. С версии 8.0 PostgreSQL конкретно этот довод против уже не работает.

* '''Python''' Модуль для Python существует уже больше десяти лет. Подробности выясняются [http://www.druid.net/pygresql/ здесь]. Установка модуля:
> sudo apt−g e t i n s t a l l python−p y g r e s q l
Более молодая и по утверждениям пользователей более стабильная библиотека для связи с PostgreSQL psycopg2 (http://initd.org/projects/psycopg2) так же устанавливается из коробки:
> sudo apt−g e t i n s t a l l python−psycopg2

* '''Ruby''' Что-то есть [http://ruby.scripting.ca/postgres/ здесь]. Установка, как обычно:
> sudo apt−g e t i n s t a l l l i bdbd −pg−ruby

* '''ODBC''' Разработка драйвера идёт на pgFoundry, аскетичная страничка проекта [http://pgfoundry.org/projects/psqlodbc/ здесь]. Установка:
> sudo apt−g e t i n s t a l l odbc−p o s t g r e s q l

==Послесловие==
Очевидно, что есть много чего ещё. При желании можно самому написать, благо родной C-интерфейс уже знаком, а логика достаточно прозрачна: открыл соединение, обменялся [SQL]-запросами и обязательно закрыл соединение. С другой стороны не стоит изобретать велосипеда и лучше для начала посмотреть, что было уже сделано, например, [http://techdocs.postgresql.org/oresources.php здесь].
===Врезка про bond===
Лень писать всё самому? Но не лень изучать XML? Тогда BOND это программа для Вас. [http://www.treshna.com/bond/ Сайт проекта].

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

Рис. 4.1. Формочки, XML (правда на заднем фоне и без подсветки) и связь с базой данных это bond

История пакета насчитывает уже пять лет. Программа доступна под GPL, то есть исходники производных продуктов надо открывать, а если хочется пожадничать, то есть версия и для такого случая, но за деньги. Доступна версия и под win32.

Внимательно читаем README и устанавливаем всё что там перечисляется. Сборка осуществляется с помощью scons, который позиционируется как замена make с функциональность automake/autoconf и синтаксисом от Python. Установка по умолчанию производится /usr/local/. Для установки (scons install ) необходимы привилегии системного администратора. Далее читаем документацию и изучаем директорию examples.

==Примечания==
<references />

LXF89:PostgreSQL

2008-03-12T12:39:02Z

PonElA: Новая: '''PostgreSQL. ЧАСТЬ 4: Интерфейсы''' :В институте им очень дорожили, так как :попутно он использовался для нек...

'''PostgreSQL. ЧАСТЬ 4: Интерфейсы'''

:В институте им очень дорожили, так как
:попутно он использовался для некоторых
:уникальных экспериментов и как переводчик
:при общении со Змеем Горынычем.
::АБС о Кощее Бессмертном

==libpq==
Чтобы общаться с базой данных много функций не надо: одна функция для открытия соединения, одна для посылки запроса, одна для получения ответа и одна для закрытия соединения. В реальности всё немного сложнее, но суть остаётся.

К вопросу о переносимости Библиотека libpq написана на чистом C, поэтому практически везде, где есть gcc, можно организовать связь с PostgreSQL. Мне както пришлось это делать для VAX/VMS всё решилось методом тыка, даже думать почти не потребовалось. Все данные текст, поэтому вопрос бинарной совместимости платформ попросту отсутствует.

С чего начать Для того чтобы воспользоваться вызовами libpq, необходимо для начала установить её. В Debian (Etch) для этого надо установить пакет postgresql-dev:
> sudo apt−g e t i n s t a l l p o s t g r e s q l −dev
Для доступа к функциям libpq необходимо включить в исходник include-файл:
#include "libpq−f e . h"

Скрипт pg_conﬁg (man pg_conﬁg) позволяет получить информацию куда помещаются include-файлы, библиотеки и тому подобное:
> #сборка программы
> g cc −o "бинарник" "исходник" . c −I ‘ pg _ co nf i g −−i n c l u d e d i r ‘ \
−l p q ‘ pg _ co nf i g −−l i b s ‘

===Открытие и закрытие соединения===

Даже открывать соединение с PostgreSQL можно двумя способами:
// открыть соединение
PGconn ∗ PQconnectdb ( const char ∗ c o n n i n f o ) ;
// то же , но не блокируя программу
PGconn ∗ PQconnectStart ( const char ∗ c o n n i n f o ) ;
// проверка ст а т уса соединения ( после PQconnectStart )
P o s t g r e s P o l l i n g S t a t u s T y p e PQconnectPoll ( PGconn ∗ conn ) ;
PQconnectdb обычная функция, где на вход подаём текстовую строку conninfo с параметрами для соединения с сервером, а на выходе получаем структуру типа PGconn с информацией о сделанном соединении и на сколько операция по соединению прошла удачно. В дальнейшем при передача данных эта переменная будет использоваться в качестве параметра.

Передача информации о серевере в качестве строки (conninfo) позволяет в случае появления дополнительных параметров не менять внешний интерфейс вызова и легко добавлять дополнительные опции. Пример открытия соединения:
const char ∗ c o n n i n f o= "dbname = t est host=lo c alho st " ;
PGconn ∗ conn=PQconnectdb ( c o n n i n f o ) ;
i f ( PQstatus ( conn ) != CONNECTION_OK) {
f p r i n t f ( s t d e r r , "Не удалось соединиться с базой данных: %s" ,
PQerrorMessage ( conn ) ) ;
/∗ завершаем работу ∗/ . . . }
Параметры передаются в форме ключевое слово = значение. Пары разделяются обычным пробелом. Пробелы вокруг знака равенства можно опустить. Если необходимо передать значение с пробелами, то его необходимо заключить в одинарные кавычки ’ составное значение ’. Для передачи одинарной кавычки её необходимо экранировать с помощью обратной косой черты \’. При отсутствии какого-либо параметра в строке conninfo его значение берётся из соответствующей переменной окружения, если такая определена. Если нет, то при открытии соединения используется значение по умолчанию.

Функции открытия соединения распознают следующие параметры и переменные окружения (кое-какие особенности опущены):
* '''host TCP/IP''' имя узла на котором находится сервер PostgreSQL. Соответствует переменной окружения PGHOST. Значение по умолчанию localhost.
* '''hostaddr''' Числовой адрес узла на котором находится PostgreSQL (альтернатива host). Соответствует переменной окружения PGHOSTADDR. Значение по умолчанию эквивалентно localhost.
* '''port''' Номер порта, который слушает POSTMASTER. Соответствует переменной окружения PGPORT. Значение по умолчанию обычно 5432.
* '''dbname''' Имя базы данных. Соответствует переменной окружения PGDATABASE. Значение по умолчанию совпадает с системной учётной записью пользователя.
* '''user''' Имя пользователя базы данных. Соответствует переменной окружения PGUSER. Значение по умолчанию совпадает с системной учётной записью пользователя.
* '''password''' Поле пароля, если для аутентификации требуется пароль. Соответствует переменной окружения PGPASSWORD. Если аутентификация требуется, а поле неопределенно, то для доступа используется информация в файле ~/.pgpass. Переменная окружения PGPASSFILE может указать другой файл для проведения аутентификации.
* '''connect_timeout''' Устанавливает максимальное время ожидания соединения в секундах. С сервером и сетью всякое может случиться. Соответствует переменной окружения PGCONNECT_TIMEOUT. Значение по умолчанию равно 0, что означает что время ожидания равно бесконечности. Не рекомендуется устанавливать значение на ожидание меньше 2 секунд.
* '''options''' Опции, посылаемые непосредственно серверу, коли такое потребуется. Соответствует переменной окружения PGOPTIONS.
* '''sslmode''' Определяет порядок действий при SSL-соединении. Принимает четыре возможных значения:
** '''disable''' без шифрации,
** '''allow''' сначала попробовать соединиться без шифрации, а в случае неудачи постараться установить защищённое соединение,
** '''prefer''' сначала попробовать установить защищённое соединения, а в случае неудачи повторить соединение без шифрации,
** '''require''' выполнять только защищённое соединение.

Соответствует переменной окружения PGSSLMODE. Значение по умолчанию prefer.
* '''krbsrvname''' Имя Kerberos-сервиса. используется для аутентификации с помощью Kerberos-5<ref>
Kerberos промышленный стандарт для аутентификации и взаимодействия в условиях незащищённого окружения. Алгоритмы Kerberos основаны на шифровании с использованием симметричного криптографического ключа и требует наличие доверенного агента.
</ref>. Это совершенно отдельная тема для беседы. Соответствует переменной окружения PGKRBSRVNAME.

PGDATESTYLE Переменная окружения, позволяющая установить представление времени и даты по умолчанию. Соответствует SQL-команде SET datestyle TO. . .
PGTZ Переменная окружения, позволяющая установить текущий часовой пояс. Соответствует SQL-команде SET timezone TO. . .
PGCLIENTENCODING Переменная окружения, позволяющая установить кодировку клиента. Соответствует SQL-команде SET client_encoding TO. . .

Существует целый класс функций, которые позволяют получить информацию о соединении. Для подробностей следует обратиться к документации. Для начала полезно знать о двух из них:
ConnStatusType PQstatus ( const PGconn ∗ conn ) ;
char ∗ PQerrorMessage ( const PGconn ∗ conn ) ;
PQstatus возвращает информацию о том, как прошло соединение. Интересны состояния CONNECTION_OK всё хорошо и CONNECTION_BAD ничего не вышло. Функция PQerrorMessage позволяет получить текстовую строку с описанием последней возникшей проблемы.

Для того чтобы разорвать соединение используется функция:
void P Q f i n i s h ( PGconn ∗ conn ) ;
{{ВНИМАНИЕ| Всегда следует закрывать соединения, когда в них отпадает нужда.}}
Число соединений которые поддерживает POSTMASTER ограничено очень легко парализовать работу базы данных только открывая новые соединения.

===SQL запросы===
Что ж, до сервера уже дозвонились , теперь пора с ним поговорить.

'''Посылка запросов''' Простейший способ выполнить SQL-запрос, это воспользоваться функцией PQexec:
PG r esul t ∗PQexec ( PGconn ∗ conn , const char ∗command ) ;
В качестве параметров передаётся структура соединения conn и строка с SQL-командой command. Возвращается указатель на структуру типа PGresult, где сохраняется информация полученная от СУБД в ответ на запрос. При желании можно в одном запросе отсылать сразу несколько SQL-команд, разделённых точкой с запятой ; , но в этом случае информация сохранённая в структуре PGresult будет относиться только к последнему запросу.

По умолчанию каждый PQexec считается за отдельную транзакцию, если явно не начать транзакцию с помощью команды BEGIN, которая будет продолжаться либо до COMMIT, либо до ROLLBACK.

Есть более сложный вызов PQexecParams, который позволяет передавать вызов и параметры к этому вызову раздельно. Таким образом исчезает необходимость самостоятельно формировать строку SQL-команды и заботиться об экранировании данных, что важно в случае сохранения бинарных последовательностей. В качестве платы из соображения безопасности PQexecParams может послать не более одной команды за раз.

В некоторых случаях для увеличения скорости выполнения часто встречающихся запросов полезно обратить внимание на парочку PQprepare и PQexecPrepared. Эти команды эквивалентны своим SQL-аналогам PREPARE и EXECUTE. Идея оптимизации состоит в том, что прежде чем выполнить запрос, PostgreSQL сначала анализирует его, затем планирует порядок действий и только потом, собственно, выполняет запрос. Первые два этапа для похожих запросов с разными условиями отбора можно выполнить заранее с помощью команды PREPARE. Затем, с помощью команды EXECUTE, можно выполнять подобные уже подготовленные (prepared)
запросы.

Все упомянутые выше команды работают с сервером БД синхронным образом, то есть посылают запрос и ждут ответа. Клиентское приложение на это время засыпает (suspended). В libpq предусмотрен целый класс функций предназначенный для асинхронных операций, не блокирующих клиентское приложение. Их применение усложняет код и логику программы, хотя всё в пределах допустимого. С моей точки зрения лучше организовать всё так, чтобы время использованное на ожидание результатов запроса фатально не влияло на внешние процессы и обеспечить бесперебойную работу сети и сервера базы данных.

'''Информация о состоянии запроса''' После выполнения запроса всегда интересно узнать каково его состояние:
ExecStatusType P Q r e s u l t S t a t u s ( const PG r esul t ∗ r e s ) ;
На вход подаётся структура PGresult, создаваемая в результате работы PQexec подобных функций, а на выходе получаем информацию о состоянии в виде числа, значение которого можно сравнить со следующими константами:
PGRES_COMMAND_OK всё прошло хорошо (для запросов, которые не возвращают данные, например, INSERT),
PGRES_TUPLES_OK всё прошло хорошо, плюс получены данные в ответ на запрос (для запросов типа SELECT или SHOW),
PGRES_EMPTY_QUERY строка запроса была почему-то пустой,
PGRES_COPY_OUT идёт передача данных от сервера,
PGRES_COPY_IN идёт передача данных на сервер,
PGRES_BAD_RESPONSE ошибка, ответ сервера не разборчив,
PGRES_NONFATAL_ERROR ошибка, не смертельно: предупреждение (notice) или информация к сведению (warning),
PGRES_FATAL_ERROR при выполнении запроса произошла серьёзная ошибка.

Для получения более подробной информации об ошибке следует воспользоваться функцией
char ∗ PQ r esul t Er r o r Messa g e ( const PG r esul t ∗ r e s ) ;
При вызове этой функции в качестве результата будет сформирована строка с информацией об ошибке или пустая строка если всё прошло хорошо.

'''Получение данных''' При получении данных предполагается, что статус запроса соответствует PGRES_TUPLES_OK. Теперь, если примерно известно что хочется получить в результате запроса, то для получения данных достаточно четырёх функций:
int PQntuples ( const PG r esul t ∗ r e s ) ;
int P Q n f i e l d s ( const PG r esul t ∗ r e s ) ;
char ∗ PQgetvalue ( const PG r esul t ∗ r e s ,
int row_number , int column_number ) ;
int P Q g e t i s n u l l ( const PG r esul t ∗ r e s ,
int row_number , int column_number ) ;
Первые две функции являются информационными и позволяют узнать сколько в результате запроса получено строк (PQntuples) и сколько колонок в каждой такой строке (PQnﬁelds). Возьмите на заметку, что 0 строк это тоже хороший результат.

Функция PQgetvalue позволяет получить доступ к полученным данным. В качестве параметров кроме структуры соединения (res) передаётся номер строки (column_number) и номер колонки (column_number). Все данные возвращаются так же в виде текстовой строки, как и посылаются, то есть, эти данные необходимо перевести в привычный формат. Например, в случае целых чисел можно восполь-
зоваться функцией atoi.

Следует помнить, что данные SQL могут иметь неопределённое значение (NULL). Если подобная возможность существует, то перед получением значения проверить, а определено ли оно. PQgetisnull позволяет разобраться с этой проблемой. По передаваемым параметрам эта функция эквивалентна PQgetvalue, а в качестве результата возвращает 1, если значение не определено и 0, если опеределено.

Кроме упомянутых существует целый ряд функций, позволяющих получить информацию о полученных данных, как то: имя колонки (PQfname), размер передаваемых данных в байтах (PQgetlength) и тому подобное. Для экранирования специальных символов при операции с бинарными или текстовыми данными есть набор сервисных функций PQescape∗.

'''COPY''' SQL команда COPY является расширением специфичным для PostgreSQL.

Основное преимущество SQL всё есть понятный текст, в некоторых случаях, когда надо передавать большие объёмы данных, оборачивается недостатком.
Функции PQputCopyData и PQgetCopyData позволяют под час значительно ускорить передачу данных между сервером и клиентом.

'''Асинхронные сигналы''' Стандартный SQL не предполагает взаимодействия разных пользователей, кроме как через изменение данных в таблицах. PostgreSQL позволяет посылать асинхронные сигналы с помощью команд LISTEN и NOTIFY. LISTEN "имя сигнала" передаётся серверу как обычная SQL-команда. Если статус запроса становится равным PGRES_COMMAND_OK, то это означает, что ранее был выполнен запрос NOTIFY "имя сигнала". Если же инициализация сигнала (NOTIFY) ожидается позже регистрации (LISTEN), то функция PQnotiﬁes позволяет после любого запроса проверить наличие сигнала вновь.

'''Сборка мусора''' Мусор убирать придётся руками. Каждая функция типа PQexec создаёт объект типа PGresult. После того как вся необходимая информация о результатах запроса получена, следует освободить память, занимаемую этим объектом с помощью команды:
void PQclear ( PG r esul t ∗ r e s ) ;
Если утечки памяти Вас не волнуют, то можно этого и не делать. В этом случае следует побеспокоиться о том: Почему Вас не беспокоят утечки памяти?

===Большие объекты===
Ещё один способ сохранять неструктурированные данные в PostgreSQL это пихать их как большие объекты (Large Objects). PostgreSQL предоставляет интерфейс схожим с файловым интерфейсом Unix: open (lo_open), read (lo_read), write (lo_write), lseek (lo_lseek) и так далее. Все lo_∗ команды работают со значениями полученными из колонки с типом oid. oid это специальный тип данных, который является ссылкой на объект произвольного типа. То есть последовательность работы с большим объектом следующая: создаётся большой объект (lo_create). Далее возвращаемый lo_create указатель Oid используется для записи данных в большой объект (lo_import/lo_write), а затем этот указатель вставляется в таблицу с помощью стандартных SQL операторов. Чтение происходит в обратном порядке (lo_export/lo_read). Все операции с большими объектами должны происходить внутри транзакции.

'''P.S.''' Необходимость интерфейса больших объектов на текущий момент не так уж и очевидна. Стандартными средствами в PostgreSQL можно сохранять бинарные данные размером вплоть до 1 Гб, что вполне может соперничать с максимальным размером для большого объекта в 2 Гб.

==ECPG==
Чтобы не отставать от коммерческих баз данных PostgreSQL имеет свой собственный вариант встроенного SQL . Эта технология позволяет смешивать обычный язык C с SQL-структурами, примерно следующим образом:

// файл test.pgc
#include <stdio.h>
#include <stdlib.h>
// структура для обработки ошибок
EXEC SQL i n c l u d e s q l c a ;
// реакция в случае ошибки/ предупреждения
EXEC SQL whenever s q l w a r n i n g s q l p r i n t ;
EXEC SQL whenever s q l e r r o r do E x i t F o r E r r o r ( ) ;
void E x i t F o r E r r o r ( ) {
f p r i n t f ( s t d e r r , "Всё , конец − это фатально .\n" ) ;
sqlprint ();
exit (1);
}
int main ( int argc , char ∗∗ argv )
{
// определение переменных , чтобы их можно было использовать
// инструкциях ECPG
EXEC SQL BEGIN DECLARE SECTION;
const char ∗dbname = " t est " ;
const char ∗ u s e r = "baldin" ;
VARCHAR FIO [ 1 2 8 ] ;
VARCHAR NUMBER[ 1 2 8 ] ;
EXEC SQL END DECLARE SECTION ;
// соединение с базой данных
// внешние переменные предваряются двоеточием
EXEC SQL CONNECT TO : dbname USER : u s e r ;
// определение курсора через SELECT
EXEC SQL DECLARE mycursor CURSOR FOR
SELECT f i o , number FROM f i o d a t a , phonedata
WHERE f i o d a t a . i d=phonedata . i d ;
EXEC SQL open mycursor ;
// чтение данных из курсора
EXEC SQL FETCH NEXT FROM mycursor INTO : FIO , :NUMBER;
while ( s q l c a . s q l c o d e == 0 ) { // не 0 , если данные больше нет
p r i n t f ( " И %s номер : %s\n" , FIO . a r r ,NUMBER. a r r ) ;
Ф О:
EXEC SQL FETCH NEXT FROM mycursor INTO : FIO , :NUMBER;
}
// разъединение с базой данных
EXEC SQL DISCONNECT;
}

Все SQL-команды начинаются с метки EXEC SQL. Эта метка позволяет затем препроцессору ecpg обработать и произвести C-исходник. Внутри SQL-команд можно использовать C-переменные. Для этого переменным в начале добавляется двоеточие : .

Для компиляции выше процитированного исходника (файл test1.pgc) необходимо выполнить следующие действия:
> # установить ecpg
> sudo apt−g e t i n s t a l l l i b e c p g −dev
> # запустить препроцессор
> ecpg t e s t 1 . pgc
> # скомпилировать получившийся исходник
> g cc −o t e s t 1 t e s t 1 . c −I ‘ pg _ co nf i g −−i n c l u d e d i r ‘ −l e c p g
> # проверка работоспособности программы
> ./ test1
ФИО: Иванов И.П. номер : 555−32−23
ФИО: Балдин Е .М. номер : 555−41−37
ФИО: Балдин Е .М. номер : (+7)5559323919

Удобно это или нет решайте сами.

==Всё остальное==
Статья называется Интерфейсы , а большая часть посвящена только одному из них. Дело в том, что этот один является родным и наиболее полным, а всё остальное лишь подмножество. В простейшем случае все интерфейсы одинаковы: открыл соединение, послал запрос, обработал результаты запроса, закрыл соединение. Так же заметна энергосберегающая тенденция везде делать ровно один интерфейс на все типы СУБД.

* '''bash''' Да, да к bash тоже есть свой интерфейс, правда для этого надо патчить его исходники. Возни, конечно, не мало зато прямо в shell-скриптах можно обращать к базе данных. [http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html Страничка проекта].

* '''Java''' Совершенно ожидаемо, что Java общается с PostgreSQL стандартным образом, а именно через JDBC. Поэтому если знаком с Java, то достаточно добыть драйвер JDBC для PostgreSQL, например [http://jdbc.postgresql.org/ отсюда] или в Debian (Sarge) набрать
> sudo apt−g e t i n s t a l l l i b p g j a v a
и, прочитав README к пакету, приступить к работе.

* '''lisp''' Точнее Common Lisp. Скорее всего эти драйвера подойдут и для других диалектов:
> sudo apt−g e t i n s t a l l c l −pg
#или
> sudo apt−g e t i n s t a l l c l −s q l −p o s t g r e s q l
Второй вариант является драйвером для единого интерфейса доступа к SQL-базам данных из Common Lisp [http://clsql.b9.com/ CLSQL].

* '''perl''' Интерфейс для связи с PostgreSQL DBD-Pg используется в perl через DBI<ref>DBI унифицированный интерфейс для доступа к данным. Подробнее об этом пакете можно посмотреть на CTAN: http://search.cpan.org/~timb/DBI-1.52/DBI.pm</ref>. Все подробности на [http://search.cpan.org/~dbdpg/DBD-Pg/Pg.pm CTAN].
> l i bdbd −pg−p e r l
DBD-Pg охватывает фактически все имеющиеся на сегодня возможности PostgreSQL от больших объектов (large objects), до точек сохранения (savepoints).

* '''PHP''' О том как использовать PostgreSQL в PHP-проектах можно прочитать [http://www.php.net/manual/en/ref.pgsql.php здесь]. Установить драйвер можно, например, так:
> sudo apt−g e t i n s t a l l php5−p g s q l
Говорят, почти единственной причиной, по которой PHP-разработчики предпочитают MySQL является то, что раньше не было родной версии PostgreSQL под альтернативную операционную систему. С версии 8.0 PostgreSQL конкретно этот довод против уже не работает.

* '''Python''' Модуль для Python существует уже больше десяти лет. Подробности выясняются [http://www.druid.net/pygresql/ здесь]. Установка модуля:
> sudo apt−g e t i n s t a l l python−p y g r e s q l
Более молодая и по утверждениям пользователей более стабильная библиотека для связи с PostgreSQL psycopg2 (http://initd.org/projects/psycopg2) так же устанавливается из коробки:
> sudo apt−g e t i n s t a l l python−psycopg2

* '''Ruby''' Что-то есть [http://ruby.scripting.ca/postgres/ здесь]. Установка, как обычно:
> sudo apt−g e t i n s t a l l l i bdbd −pg−ruby

* '''ODBC''' Разработка драйвера идёт на pgFoundry, аскетичная страничка проекта [http://pgfoundry.org/projects/psqlodbc/ здесь]. Установка:
> sudo apt−g e t i n s t a l l odbc−p o s t g r e s q l

==Послесловие==
Очевидно, что есть много чего ещё. При желании можно самому написать, благо родной C-интерфейс уже знаком, а логика достаточно прозрачна: открыл соединение, обменялся [SQL]-запросами и обязательно закрыл соединение. С другой стороны не стоит изобретать велосипеда и лучше для начала посмотреть, что было уже сделано, например, [http://techdocs.postgresql.org/oresources.php здесь].
===Врезка про bond===
Лень писать всё самому? Но не лень изучать XML? Тогда BOND это программа для Вас. [http://www.treshna.com/bond/ Сайт проекта].

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

Рис. 4.1. Формочки, XML (правда на заднем фоне и без подсветки) и связь с базой данных это bond

История пакета насчитывает уже пять лет. Программа доступна под GPL, то есть исходники производных продуктов надо открывать, а если хочется пожадничать, то есть версия и для такого случая, но за деньги. Доступна версия и под win32.

Внимательно читаем README и устанавливаем всё что там перечисляется. Сборка осуществляется с помощью scons, который позиционируется как замена make с функциональность automake/autoconf и синтаксисом от Python. Установка по умолчанию производится /usr/local/. Для установки (scons install ) необходимы привилегии системного администратора. Далее читаем документацию и изучаем директорию examples.

==Примечания==
<references />

LXF86:PostgreSQL

2008-03-12T12:24:42Z

PonElA: /* См.также */

<<[[LXF86]]

'''PostgreSQL. ЧАСТЬ 2: Работа с базой'''

Проблема компьютеров в том, что они делают то, что вы сказали, а не то, что подумали. Поэтому запустить PostgreSQL недостаточно – нужно еще суметь договориться с ним на понятном языке. [[Балдин Евгений|Евгений Балдин]] открывает русско-машинный словарь...

:Это прибор, – сказал Корнеев безнадежно. – С ним работают...
::«Понедельник начинается в субботу»
==Работа с базой==
'''В''' прошлой части мы узнали, как создать базу данных и запустить postmaster. Теперь дело за малым: надо научиться сохранять данные и «доступаться» до них. Для этого следует договориться с postmaster – благо его «родной» язык довольно высокоуровневый.

Как и в предыдущей части, все рассматривается с точки зрения дистрибутива Debian (Sarge). При прочтении следует иметь это в виду.
{| class="standard"
!Год||Ревизия||Нововведения
|-
|1986||SQL-86, SQL-87|| Первая версия стандарта ANSI. Принят ISO в 1987 году. Стандартизация синтаксиса.
|-
|1989||SQL-89 || Стандартизован механизм ссылочной целостности.
|-
|1992||SQL-92 (SQL-2)||Множество нововведений. В отличие от предыдущих версий, где стандарт просто сертифицировал уже имеющиеся на рынке реляционных БД возможности, были заложены основы для развития языка. Введены три уровня соответствия стандарту Entry (начальный), Intermediate (промежуточный), Full (полный). Мало какая из баз данных поддерживает SQL-92 лучше, чем Entry.
|-
|1999 ||SQL:1999 (SQL-3) || Добавлены регулярные выражения, рекурсивные запросы, триггеры. Определена интеграция с объектно-ориентированным подходом. Вместо трех уровней соответствия введен набор свойств (features).
|-
|2003||SQL:2003 ||Стандартизованы XML-зависимые нововведения, интервальные функции (window functions), стандартные последовательности и столбцы с автоматически генерируемыми значениями.
|}

==SQL==
В качестве языка общения с реляционными базами данных в подавляющем большинстве случаев используется [[SQL]]. Изначально эти три буквы были сокращением фразы Structured Query Language (язык структурированных запросов). Сейчас, когда язык стал стандартом,SQL уже не является аббревиатурой – это обычное название, которое произносится как «эс-кью-эл». Несмотря на это, даже англоязычные специалисты по прежнему часто называют SQL «сиквел». По-русски также часто говорят «эс-ку-эль».

У этого языка есть недостатки, приводящие к тому, что в реальности SQL дополняется различными расширениями. Кстати, сам Кодд, «отец» реляционных баз данных, считал SQL неудачной реализацией его теории. Но на сегодня это мощный открытый промышленный стандарт, который позволяет решать множество типовых задач по созданию, модификации и управлению данными – он есть здесь и сейчас.

За время своего существования SQL претерпел несколько ревизий. Основные вехи в истории стандарта перечислены в таблице.
Степень соответствия PostgreSQL стандарту SQL:2003 подробно рассмотрена в Приложении D (Appendix D. SQL Conformance) стандартной документации.

Там же есть и простейший учебник, и исчерпывающий справочник по SQL. Существует море литературы, в которой подробно и не очень рассказывается, что же это за «зверь такой» – SQL. Необходимый для «вхождения в технологию» минимум настолько прост, что основы изучаются в пределах одного дня вдумчивого чтения учебника.

Для того, чтобы куда-то сохранить данные, необходимо создать«хранилище» – таблицу/таблицы:
CREATE TABLE fiodata (id int,fio text)
CREATE TABLE phonedata (id int,number text)
Теперь можно добавлять данные:
INSERT INTO fiodata VALUES (1,’Иванов И.П.’)
INSERT INTO phonedata VALUES (1,’555-32-23’)
и так далее. Мы создали две обычных таблицы «без наворотов»: в одной хранятся имена, а в другой – телефоны. Сопоставление телефонов именам происходит через поля id. Почему так? На одно имя может быть заведено несколько телефонов, а на одном телефоне может «сидеть» несколько человек.

Теперь надо извлечь данные, и в этом нам поможет оператор SELECT. Собственно говоря, пользователю, кроме этого оператора, больше ничего знать и не надо – все выборки делаются с его помощью. Выведем все имена и соответствующие им телефоны:
SELECT fio, number
FROM fiodata,phonedata WHERE fiodata.id=phonedata.id
SQL, очевидно, заслуживает большего, чем это «микровведение», и его, в любом случае, придется изучать тем, кто реально хочет заниматься базами данных – то есть от книжек никуда не денешься. А если подходить к делу серьезно, то кроме описания SQL следует изучить и основы реляционных баз данных того же К.Дж. Дейта (C.J. Date) – но это уже совсем другая история.

==Командная строка==
Когда набирается текст, а SQL – это именно текст, то лучше, чтобы ничего вокруг не отвлекало. Надежная, «толстая» и дешевая связь – вещь хорошая, только вот случается она не всегда, так что командная строка оказывается вне конкуренции.

==psql==

Вместе с пакетом postgresql-client поставляется утилита psql – интерактивная оболочка для «разговоров» с PostgreSQL. Она же – лучший инструмент для администрирования.

Окно psql.

Пусть существует база данных test, в которой заведены таблицы fiodata и phonedata, описанные в предыдущем разделе. Подсоединимся к базе и что-нибудь «спросим» у нее:
> psql test
Добро пожаловать в pSQL 7.4.7 – Интерактивный Терминал PostgreSQL.
Наберите: \copyright для условий распространения
'''\h''' для подсказки по SQL командам
'''\?''' для подсказки по внутренним slash-командам (\команда)
'''\g''' или “;” для завершения и выполнения запроса
'''\q''' для выхода

test=> SELECT fio, number
test-> FROM fiodata,phonedata WHERE fiodata.id=phonedata.id;
fio | number
-------------+----------------
Иванов И.П. | 555-32-23
Балдин Е.М. | 555-41-37
Балдин Е.М. | (+7)5559323919
(записей: 3)

Если хочется подсоединиться к серверу на другой машине, то нужно указать имя машины после ключа -h. Ключ -U позволяет указать имя пользователя.
{{Врезка|right|Ширина=200px
|Заголовок=Скорая помощь
|Содержание=После первого запуска PgAccess необходимо настроить шрифты:

Database->Preferences->Look & Feel.

Логика их выбора по умолчанию не совсем, с моей точки зрения,адекватна, с другой стороны – при желании это настраивается.}}

psql передает SQL-команды на сервер. Обратите внимание, что для завершения SQL-команды используется точка с запятой – ;.

Как и всякая человеко-ориентированная оболочка, pSQL использует библиотеку Readline. Это означает наличие стандартных горячих emacs-подобных комбинаций символов для общепринятого редактирования ввода командной строки, в том числе и завершение SQL-команд по Tab. По клавише Tab завершаются не только SQL-команды, но и названия таблиц и имена колонок, если это возможно.

psql поддерживает историю команд, которая сохраняется в .pSQL_history. Это также особенность библиотеки Readline. Полезным является интерактивный поиск по истории команд, который вызывается с помощью комбинации C^r.

Кроме команд SQL, psql имеет набор собственных специальных команд. Все такие команды начинаются с обратной косой черты \. Число спецкоманд довольно обширно и полное их описание можно распечатать, выполнив команду man pSQL. Далее будет перечислены наиболее интересные из них:

*'''\q''' Закончить работу с pSQL. Выйти из оболочки.
*'''\?''' Вывести справку по имеющимся спец-командам.
*'''\h''' [SQL-команда] Вывести помощь по запрашиваемой SQL-команде в форме Бэкуса-Наура (Backus Naur Form). SQL-команда может состоять из нескольких слов. При исполнении \h без аргумента выводится список доступных SQL-команд.
*'''\!''' [shell-команда] Запустить командный интерпретатор и выполнить команду оболочки.
*'''\i''' «файл» Прочитать текстовый файл и выполнить имеющиеся в нем команды. Удобно для нетривиальных операций.

Имя файла с командами можно передать при запуске psql посредством ключа -f. В этом случае после чтения и исполнения всех команд psql автоматически прекращает работу.
*'''\o''' [«файл»] Сохранить результаты выполнения будущих команд в файл. Если аргумент отсутствует, то вывод переключается на терминал. psql имеет набор команд, которые позволяют сформировать вывод в удобном для пользователя виде.

Имя файла, в котором следует сохранить результаты, также можно передать при запуске psql с помощью ключика -o. Этот ключ удобно применять совместно с ключом -f.
*'''d''' [«регулярное выражение»] Вывести структуру объекта. Годится для таблицы (table), представления (view), индекса (indexes) или последовательности (sequences). Список объектов можно получить, добавив первую букву названия объекта t, v, i, s к команде \d.

В дополнение к вышесказанному, psql поддерживает простейший механизм присваивания значений собственным переменным и их интерполяции в SQL-запросах:
test=> \set proba ‘phonedata’
test=> select * from :proba;
id | number
----+----------------
2 | 555-41-37
2 | (+7)5559323919
1 | 555-32-23
(записей: 3)

Следует учитывать, что интерполяция переменных не работает, если переменная используется внутри SQL-строки. В любом случае, хоть какое-то подспорье.

==gql-shell==
Небольшая psql-подобная оболочка, написанная одним человеком. Разработка заморожена. Естественно, она не обладает всеми возможностями psql, зато может подсоединяться и «разговаривать» не только с PostgreSQL. Для подсоединения к базе данных используется библиотека GQL (Generic C++ SQL Library). Для работы с PostgreSQL необходимо установить драйвер:
> sudo apt-get install gql-shell
> sudo apt-get install libgql-driver-0.5-pg
> gql-shell pg:test
Welcome to gql-shell, the interactive SQL terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

test=>

==dbishell==
dbishell – интерактивная оболочка на основе Perl::DBI. Как и gql-shell, поддерживает не только PostgreSQL. dbishell представляет из себя скрипт на Perl и занимает при установке чуть больше 150 Кб.
> sudo apt-get install dbishell
> dbishell --driver Pg --dsn host=localhost\;database=test --user baldin
Password:
Using DBIShell::dr::Pg engine

dbi:Pg:host=localhost;database=test:baldin>quit/
Для завершения любой команды используется косая черта /.

==GUI вам в помощь==
Следует признать, что программа с графическим пользовательским интерфейсом выглядит гораздо солиднее какой-то там командной строки. Об эффективности работы в случае необходимости показать, что занят важным делом, речь, естественно, не идет. Зачем один терминал, когда можно открыть кучу красивеньких окошечек с иконками? Конечно, PostgreSQL позволяет разговаривать с собой и через окна.

==PgAccess==
Когда обсуждается графический пользовательский интерфейс к PostgreSQL, тут же всплывает слово PgAccess (http://www.pgaccess.org/). PgAccess создан Константином Теодореску (Constantin Teodorescu) и имеет довольно длительную историю развития. На текущий момент разработка, похоже, заморожена. С другой стороны, «нет худа без добра»: новых версий тащить не надо – достаточно поставить то, что идет стандартно с вашим дистрибутивом:
> sudo apt-get install PgAccess
> PgAccess
Для того, чтобы подсоединиться к базе данных необходимо воспользоваться диалогом открытия соединения: Database -> Open. По умолчанию предполагается, что postmaster запущен на этом же компьютере (Host: localhost), и он «слушает» порт номер 5432 – если при установке PostgreSQL ничего специально не делалось, то так оно и есть. Далее требуется указать базу данных, к которой надо подсоединиться, пользователя и, если необходимо, пароль.

PgAccess явно что-то умеет.

PgAccess – это кросс-платформенный графический интерфейс к PostgreSQL написанный на чистом Tcl/Tk, и как следствие этого, работает везде, где этот инструментарий имеется (даже на «альтернативной» платформе). Размер дистрибутива по современным меркам крошечный: при установке все укладывается в 4 Мб.

В программе есть возможность создавать, редактировать и просматривать таблицы, запросы, представления, функции, пользователей, то есть довольно многое из того, что можно делать c помощью SQL. Плюс к этому можно создавать графические формы для ввода/просмотра данных, рисовать простые диаграммы и графики, просматривать картинки, сохраненные в базе данных. Так как программа написана на Tcl/Tk, то есть возможность писать свои скрипты, используя объекты, уже определенные в PgAccess.

Если хочется «сляпать» на скорую руку формочку, которую мож но запустить фактически где угодно после минимальной доводки, то PgAccess вполне может подойти для этого дела. В самом PgAccess масса ограничений и недостатков, но так как программа относительно небольшая, то ее можно доделать «по месту».

Информацию о созданных формах, запросах и тому подобных объектах PgAccess сохраняет непосредственно в базе данных, в таблицах, начинающихся с префикса pga_. Так что то, что сделано кем-то одним, будет доступно и всем пользователям базы.

Наличие PgAccess на машине, с моей точки зрения, поощряет нездоровое желание что-то «сляпать», а не сделать по-человечески. Так что работать с этим предметом надо осторожно, и если нет необходимости, то лучше убрать его от греха подальше. По мне, так pSQL гораздо удобнее и эффективнее, а самое главное – пользователи наведываются в БД гораздо реже.

==pgAdmin III==
Программа порадует вас заявлением, что она наиболее популярная и функциональная платформа администрирования и разработки для PostgreSQL, а также своим отсутствием в дистрибутиве Debian (Sarge), посему установка начнется с ее выкачивания. К счастью, на сайте проекта http://www.pgadmin.org/ можно найти сборки под множество дистрибутивов. Есть и специальный репозитарий для Debian – в /etc/apt/source.list добавляется строка:
deb [MIRROR URL]/pgadmin3/release/debian sarge pgadmin
где вместо [MIRROR URL] подставляется одно из официальных зеркал PostgreSQL, например: ftp://ftp.ru.PostgreSQL.org/pub/mirrors/pgSQL, и производится установка программы:
> sudo apt-get update
> sudo apt-get install pgadmin3
> pgadmin3
При этом скачивается около 7,5 Мб. После запуска можно убедиться, что программа выглядит вполне солидно.

pgAdmin III подробно объясняет что надо «сказать» чтобы создать выбранный объект.

Новое соединение создается через меню File Add server. Требуется указать Address (localhost для локальной машины), сделать краткое описание соединения (Description), выбрать базу данных (Maintenance DB) и пользователя. После подсоединения доступны все объекты, которыми может управлять текущий пользователь.

PgAdmin III – это продукт для администрирования и управления базами данных под управлением PostgreSQL и его потомков. PgAdmin III содержит в себе графический интерфейс для управления данными, SQL-редактор с графическим представлением EXPLAIN, имеет инструменты для создания и редактирования таблиц, умеет управляться с системой репликации Slony-I и многое другое, что действительно упрощает администрирование. И все-таки PgAdmin III не для пользователя. Пока нет понимания того, что происходит, не следует уповать на картинки.

Изначально pgAdmin разрабатывался под Windows, но на сегодня этот продукт является многоплатформенным решением и работает также под Linux, Mac OSX, FreeBSD и Solaris. В качестве графической библиотеки используется wxWidgets (http://www.wxwidgets.org).

Русский перевод интерфейса, в принципе, существует, но на текущий момент не поддерживается. С другой стороны, это прежде всего инструмент администрирования и управления данными. В любом случае, разработчики приветствуют новые и обновленные переводы.
==TOra==
TOra возникла благодаря тому, что Генри Джонсон (Henrik Johnson) не смог запустить VMWare с Windows в далеком 2000 году. В то же время ему хотелось иметь графическую утилиту для администрирования Oracle, подобную той, которой пользовались его друзья, так и не отошедшие от «окон». TOra – это toolkit for Oracle. Так было, но на сегодня (в том числе и вследствие того, что TOra написана с использованием библиотеки Qt3), также можно работать и с PostgreSQL. Кроме PostgreSQL, дополнительно поддерживается MySQL и все, что работает через ODBC.
<ref>Вследствие того, что PostgreSQL распространяется под лицензией BSD, имеется несколько
коммерческих продуктов, основанных на его коде, например, EnterpriseDB, Pervasive Postgres и SRA PowerGres.0</ref>

Установка и запуск TOra просты:
> sudo apt-get install TOra
> TOra
TOra предлагает диалог создания нового соединения сразу при старте. Требуется указать Connection рrovider (PostgreSQL), Username, Host (localhost), Port (5432) и DataBase.
Из-за прошлого программы, многие возможности TOra оказались привязаны к особенностям Oracle. В случае работы с PostgreSQL, TOra полезна прежде всего как браузер по SQL-объектам, SQL-терминал и изощренный SQL-редактор. Как и в случае pgAdmin III, TOra позволяет создавать и редактировать таблицы с помощью графических диалогов, но не владеет специфичными для PostgreSQL настройками.
TOra – это крепко «сбитый» программный продукт, который позволяет работать с разными реляционными СУБД в пределах одной программы.

==OpenOffice.org и SDBC==
OpenOffice.org – монстр, но ситуация на сегодня такая, что люди любят монстров, и ничего в обозримом будущем с этим не поделаешь.

OpenOffice + PostgreSQL.

Для прямого доступа из OpenOffice к PostgreSQL без промежуточного уровня в виде ODBC/JDBC драйверов разрабатывается драйвер PostgreSQL-sdbc. На сегодня в стандартной поставке OpenOffice.org этот пакет отсутствует.

Для установки необходимо скачать zip-архив этого драйвера с его домашней странички [http://dba.OpenOffice.org/drivers/PostgreSQL/index.html OpenOffice.org] и положить куда-нибудь у себя на диске не распаковывая (!). Далее, запустив OpenOffice, следует открыть диалог управления пакетами: Сервис Управление пакетами… и с помощью кнопки Добавить установить этот пакет. В моем случае после установки пришлось перезапустить OpenOffice.

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

Создать Базу данных Выбор базы данных, поставить галочку Подключиться к существующей базе данных и выбрать PostgreSQL. Далее при настройке соединения в следует ввести строчку вида:
dbname=”имя БД” host=”адрес сервера”
подставив вместо имя БД и адрес сервера имя предварительно созданной базы данных и адрес сервера, на котором «крутится» postmaster, например, dbname=test host=localhost. Далее, во вкладке Аутентификация пользователя необходимо ввести имя пользователя – затем можно протестировать соединение. Если тест прошел нормально, то можно продолжить и выполнить подключение.

Во время окончания действия мастера предлагается сохранить все, что проделано в ODB-файле (формат База данных OpenDocument). Затем это соединение можно будет выполнить простым открытием файла. Туда же сохраняется информация обо всех созданных формах, запросах и отчетах. Как конкретно создаются формы и отчеты – это совсем другая история и относится она не к PostgreSQL, а к OpenOffice.org (см.[[LXF85:PostgreSQL]]).

При выборе таблиц легко видеть, что они в PostgreSQL разбиты на группы. Пользовательские таблицы по умолчанию находятся в группе public. В группах pg_catalog и informaion_schema представлена системная информация и статистика.

==Что выбрать?==
Естественно, мы рассмотрели далеко не все возможные программы общего назначения для работы с PostgreSQL, но даже из того, что рассмотрено, нельзя выбрать что-то одно. Каждая программа имеет свои особенности и преимущества. psql позволяет легко работать удаленно, OpenOffice.org удовлетворяет нашу любовь к монстрам, PgAdmin III содержит множество подсказок по делу, PgAccess удивляет своей интеграцией с TCL/Tk, а TOra – «просто красивая».

Я всегда выбирал psql, но это скорее всего связано со специфичностью решаемых мной задач. Я вполне могу представить себе ситуацию, когда наличие, например, TOra значительно облегчит жизнь. Ну и не следует забывать про данные, которые кто-то должен вводить. Если лень писать специальную программу (которую лучше все-таки написать), то OpenOffice.org поможет, особенно если вводить не вам.

==См.также==
* [[Азбука SQL]]

==Примечания==
<references />

Азбука SQL

2008-03-12T12:23:50Z

PonElA: Новая: ==Язык определения данных== Группа операторов SQL, ответственных за описание и модификацию структуры БД...

==Язык определения данных==
Группа операторов SQL, ответственных за описание и модификацию структуры БД, представляет собой специализированный язык определения данных (Data Definition Language).
Язык определения данных включает следующие операторы:
*'''CREATE''' – позволяет создать новую базу данных, таблицу (TABLE), индекс (INDEX), представление (VIEW) или какую-либо другую сущность,
*'''DROP''' – позволяет удалить то, что было создано с помощью CREATE,
*'''ALTER''' – позволяет изменить параметры уже существующего объекта.
Из перечисленных наиболее популярна команда создания таблиц:
*'''CREATE TABLE''' «имя таблицы» («имя столбца 1» «тип данных» [DEFAULT «значение по умолчанию»] [«ограничения на столбец»],[«имя столбца 2» …,][…,] [«ограничения на таблицу»])

Ключевое слово DEFAULT предваряет значение, которое присваивается, если при вставке данных отсутствует инициализация.
Ограничения, накладываемые на столбец, могут характеризоваться ключевыми словами:
*'''NOT NULL''' – инициализация при вставке обязательна.
*'''UNIQUE''' – значение должно быть уникальным.
*'''PRIMARY KEY''' – значение объявляется первичным ключом. В таблице может быть ровно один первичный ключ. Значение, объявленное первичным ключом должно быть определенным и уникальным (NOT NULL+UNIQUE)
*'''CHECK'''(«условное выражение») – проверка значения.
*'''REFERENCES''' – ссылка на допустимый диапазон значений, представленных во внешней таблице (внешний ключ FOREIGN KEY).
Ограничения, накладываемые на таблицу в целом, дублируют описанную функциональность, позволяя при составлении требований использовать имена несколько столбцов. Например, первичный ключ вполне может быть составным.
*'''DROP TABLE''' позволяет уничтожить таблицу, созданную CREATE TABLE. Синтаксис команды уничтожения гораздо проще команды созидания. Надо только добавить «имя таблицы». Это очень опасная для данных команда.
Довольно редко, но все же бывает необходимо изменить уже существующую таблицу:
*'''ALTER TABLE''' «имя таблицы» «действие»
В качестве «действия» можно добавить столбец или ограничение (ADD), удалить столбец или ограничение (DROP), изменить параметра столбца (ALTER), а так же «повесить»/«выключить» триггер (ENABLE/DISABLE TRIGGER).

==Язык манипулирования данными==

Группа операторов SQL, ответственных за добавление, удаление и модификацию данных, представляет из себя специализированный язык манипулирования данными (Data Manipulation Language).

Язык манипулирования данными включает следующие операторы:
*'''INSERT''' – позволяет добавить одну или несколько строк (rows) данных в уже существующую таблицу,
*'''UPDATE''' – позволяет изменить уже существующие данные,
*'''DELETE''' – позволяет удалить одну и более строк данных из таблицы,
*'''TRUNCATE''' – позволяет очистить одну или несколько таблиц от данных (очень опасная команда).

Для вставки данных следует воспользоваться командой:
INSERT INTO «имя таблицы»
[(«список столбцов»)] VALUES («список значений»)
Столбцы и значения в соответствующих списках разделяются запятыми. При отсутствии списка столбцов значения присваиваются в соответствии с порядком именования столбцов при создании таблицы.

В качестве значения команде INSERT можно передать null. Это эквивалентно тому, что соответствующее поле не инициализируется при вставке.

Для модификации данных следует использовать команду:
UPDATE «имя таблицы»
SET «столбец»=«значение» [,…]
[ WHERE «условное выражение» ]
Условные выражения могут объединяться по «и» (AND) или по «или» (OR). Логика в SQL – трехзначная. Кроме ожидаемых значений для условных выражений, таких как «истина» (true) и «ложь» (false), допустимо значение «не определено» (unknown).
{| border=1 width="50%"
|+ '''Таблица 1: Таблица истинности для оператора OR.'''
| bgcolor=#CCFF00|OR
| bgcolor=#CCFF00|TRUE
| bgcolor=#CCFF00|FALSE
| bgcolor=#CCFF00|UNKNOWN
|-
|'''TRUE'''
|true
|true
|true
|-
|'''FALSE'''
|true
|false
|unknown
|-
|'''UNKNOWN'''
|true
|unknown
|unknown
|}

{| border=1 width="50%"
|+ '''Таблица 2: Таблица истинности для оператора AND.'''
| bgcolor=#CCFF00|AND
| bgcolor=#CCFF00|TRUE
| bgcolor=#CCFF00|FALSE
| bgcolor=#CCFF00|UNKNOWN
|-
|'''TRUE'''
|true
|false
|unknown
|-
|'''FALSE'''
|false
|false
|false
|-
|'''UNKNOWN'''
|unknown
|false
|unknown
|}

Для удаления данных используются команды:
DELETE FROM «имя таблицы»
[ WHERE «условное выражение» ]
или
TRUNCATE TABLE «имя таблицы» [, …]
Как это ни печально, но удалять гораздо проще, чем добавлять их. Не следует злоупотреблять этими операторами.

TOra знает все об SQL и кое-что сверх того.»

LXF86:PostgreSQL

2008-03-12T12:20:37Z

PonElA: /* OpenOffice.org и SDBC */

LXF86:PostgreSQL

2008-03-12T12:19:25Z

PonElA: /* OpenOffice.org и SDBC */

<<[[LXF86]]

'''PostgreSQL. ЧАСТЬ 2: Работа с базой'''

Проблема компьютеров в том, что они делают то, что вы сказали, а не то, что подумали. Поэтому запустить PostgreSQL недостаточно – нужно еще суметь договориться с ним на понятном языке. [[Балдин Евгений|Евгений Балдин]] открывает русско-машинный словарь...

:Это прибор, – сказал Корнеев безнадежно. – С ним работают...
::«Понедельник начинается в субботу»
==Работа с базой==
'''В''' прошлой части мы узнали, как создать базу данных и запустить postmaster. Теперь дело за малым: надо научиться сохранять данные и «доступаться» до них. Для этого следует договориться с postmaster – благо его «родной» язык довольно высокоуровневый.

Как и в предыдущей части, все рассматривается с точки зрения дистрибутива Debian (Sarge). При прочтении следует иметь это в виду.
{| class="standard"
!Год||Ревизия||Нововведения
|-
|1986||SQL-86, SQL-87|| Первая версия стандарта ANSI. Принят ISO в 1987 году. Стандартизация синтаксиса.
|-
|1989||SQL-89 || Стандартизован механизм ссылочной целостности.
|-
|1992||SQL-92 (SQL-2)||Множество нововведений. В отличие от предыдущих версий, где стандарт просто сертифицировал уже имеющиеся на рынке реляционных БД возможности, были заложены основы для развития языка. Введены три уровня соответствия стандарту Entry (начальный), Intermediate (промежуточный), Full (полный). Мало какая из баз данных поддерживает SQL-92 лучше, чем Entry.
|-
|1999 ||SQL:1999 (SQL-3) || Добавлены регулярные выражения, рекурсивные запросы, триггеры. Определена интеграция с объектно-ориентированным подходом. Вместо трех уровней соответствия введен набор свойств (features).
|-
|2003||SQL:2003 ||Стандартизованы XML-зависимые нововведения, интервальные функции (window functions), стандартные последовательности и столбцы с автоматически генерируемыми значениями.
|}

==SQL==
В качестве языка общения с реляционными базами данных в подавляющем большинстве случаев используется [[SQL]]. Изначально эти три буквы были сокращением фразы Structured Query Language (язык структурированных запросов). Сейчас, когда язык стал стандартом,SQL уже не является аббревиатурой – это обычное название, которое произносится как «эс-кью-эл». Несмотря на это, даже англоязычные специалисты по прежнему часто называют SQL «сиквел». По-русски также часто говорят «эс-ку-эль».

У этого языка есть недостатки, приводящие к тому, что в реальности SQL дополняется различными расширениями. Кстати, сам Кодд, «отец» реляционных баз данных, считал SQL неудачной реализацией его теории. Но на сегодня это мощный открытый промышленный стандарт, который позволяет решать множество типовых задач по созданию, модификации и управлению данными – он есть здесь и сейчас.

За время своего существования SQL претерпел несколько ревизий. Основные вехи в истории стандарта перечислены в таблице.
Степень соответствия PostgreSQL стандарту SQL:2003 подробно рассмотрена в Приложении D (Appendix D. SQL Conformance) стандартной документации.

Там же есть и простейший учебник, и исчерпывающий справочник по SQL. Существует море литературы, в которой подробно и не очень рассказывается, что же это за «зверь такой» – SQL. Необходимый для «вхождения в технологию» минимум настолько прост, что основы изучаются в пределах одного дня вдумчивого чтения учебника.

Для того, чтобы куда-то сохранить данные, необходимо создать«хранилище» – таблицу/таблицы:
CREATE TABLE fiodata (id int,fio text)
CREATE TABLE phonedata (id int,number text)
Теперь можно добавлять данные:
INSERT INTO fiodata VALUES (1,’Иванов И.П.’)
INSERT INTO phonedata VALUES (1,’555-32-23’)
и так далее. Мы создали две обычных таблицы «без наворотов»: в одной хранятся имена, а в другой – телефоны. Сопоставление телефонов именам происходит через поля id. Почему так? На одно имя может быть заведено несколько телефонов, а на одном телефоне может «сидеть» несколько человек.

Теперь надо извлечь данные, и в этом нам поможет оператор SELECT. Собственно говоря, пользователю, кроме этого оператора, больше ничего знать и не надо – все выборки делаются с его помощью. Выведем все имена и соответствующие им телефоны:
SELECT fio, number
FROM fiodata,phonedata WHERE fiodata.id=phonedata.id
SQL, очевидно, заслуживает большего, чем это «микровведение», и его, в любом случае, придется изучать тем, кто реально хочет заниматься базами данных – то есть от книжек никуда не денешься. А если подходить к делу серьезно, то кроме описания SQL следует изучить и основы реляционных баз данных того же К.Дж. Дейта (C.J. Date) – но это уже совсем другая история.

==Командная строка==
Когда набирается текст, а SQL – это именно текст, то лучше, чтобы ничего вокруг не отвлекало. Надежная, «толстая» и дешевая связь – вещь хорошая, только вот случается она не всегда, так что командная строка оказывается вне конкуренции.

==psql==

Вместе с пакетом postgresql-client поставляется утилита psql – интерактивная оболочка для «разговоров» с PostgreSQL. Она же – лучший инструмент для администрирования.

Окно psql.

Пусть существует база данных test, в которой заведены таблицы fiodata и phonedata, описанные в предыдущем разделе. Подсоединимся к базе и что-нибудь «спросим» у нее:
> psql test
Добро пожаловать в pSQL 7.4.7 – Интерактивный Терминал PostgreSQL.
Наберите: \copyright для условий распространения
'''\h''' для подсказки по SQL командам
'''\?''' для подсказки по внутренним slash-командам (\команда)
'''\g''' или “;” для завершения и выполнения запроса
'''\q''' для выхода

test=> SELECT fio, number
test-> FROM fiodata,phonedata WHERE fiodata.id=phonedata.id;
fio | number
-------------+----------------
Иванов И.П. | 555-32-23
Балдин Е.М. | 555-41-37
Балдин Е.М. | (+7)5559323919
(записей: 3)

Если хочется подсоединиться к серверу на другой машине, то нужно указать имя машины после ключа -h. Ключ -U позволяет указать имя пользователя.
{{Врезка|right|Ширина=200px
|Заголовок=Скорая помощь
|Содержание=После первого запуска PgAccess необходимо настроить шрифты:

Database->Preferences->Look & Feel.

Логика их выбора по умолчанию не совсем, с моей точки зрения,адекватна, с другой стороны – при желании это настраивается.}}

psql передает SQL-команды на сервер. Обратите внимание, что для завершения SQL-команды используется точка с запятой – ;.

Как и всякая человеко-ориентированная оболочка, pSQL использует библиотеку Readline. Это означает наличие стандартных горячих emacs-подобных комбинаций символов для общепринятого редактирования ввода командной строки, в том числе и завершение SQL-команд по Tab. По клавише Tab завершаются не только SQL-команды, но и названия таблиц и имена колонок, если это возможно.

psql поддерживает историю команд, которая сохраняется в .pSQL_history. Это также особенность библиотеки Readline. Полезным является интерактивный поиск по истории команд, который вызывается с помощью комбинации C^r.

Кроме команд SQL, psql имеет набор собственных специальных команд. Все такие команды начинаются с обратной косой черты \. Число спецкоманд довольно обширно и полное их описание можно распечатать, выполнив команду man pSQL. Далее будет перечислены наиболее интересные из них:

*'''\q''' Закончить работу с pSQL. Выйти из оболочки.
*'''\?''' Вывести справку по имеющимся спец-командам.
*'''\h''' [SQL-команда] Вывести помощь по запрашиваемой SQL-команде в форме Бэкуса-Наура (Backus Naur Form). SQL-команда может состоять из нескольких слов. При исполнении \h без аргумента выводится список доступных SQL-команд.
*'''\!''' [shell-команда] Запустить командный интерпретатор и выполнить команду оболочки.
*'''\i''' «файл» Прочитать текстовый файл и выполнить имеющиеся в нем команды. Удобно для нетривиальных операций.

Имя файла с командами можно передать при запуске psql посредством ключа -f. В этом случае после чтения и исполнения всех команд psql автоматически прекращает работу.
*'''\o''' [«файл»] Сохранить результаты выполнения будущих команд в файл. Если аргумент отсутствует, то вывод переключается на терминал. psql имеет набор команд, которые позволяют сформировать вывод в удобном для пользователя виде.

Имя файла, в котором следует сохранить результаты, также можно передать при запуске psql с помощью ключика -o. Этот ключ удобно применять совместно с ключом -f.
*'''d''' [«регулярное выражение»] Вывести структуру объекта. Годится для таблицы (table), представления (view), индекса (indexes) или последовательности (sequences). Список объектов можно получить, добавив первую букву названия объекта t, v, i, s к команде \d.

В дополнение к вышесказанному, psql поддерживает простейший механизм присваивания значений собственным переменным и их интерполяции в SQL-запросах:
test=> \set proba ‘phonedata’
test=> select * from :proba;
id | number
----+----------------
2 | 555-41-37
2 | (+7)5559323919
1 | 555-32-23
(записей: 3)

Следует учитывать, что интерполяция переменных не работает, если переменная используется внутри SQL-строки. В любом случае, хоть какое-то подспорье.

==gql-shell==
Небольшая psql-подобная оболочка, написанная одним человеком. Разработка заморожена. Естественно, она не обладает всеми возможностями psql, зато может подсоединяться и «разговаривать» не только с PostgreSQL. Для подсоединения к базе данных используется библиотека GQL (Generic C++ SQL Library). Для работы с PostgreSQL необходимо установить драйвер:
> sudo apt-get install gql-shell
> sudo apt-get install libgql-driver-0.5-pg
> gql-shell pg:test
Welcome to gql-shell, the interactive SQL terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

test=>

==dbishell==
dbishell – интерактивная оболочка на основе Perl::DBI. Как и gql-shell, поддерживает не только PostgreSQL. dbishell представляет из себя скрипт на Perl и занимает при установке чуть больше 150 Кб.
> sudo apt-get install dbishell
> dbishell --driver Pg --dsn host=localhost\;database=test --user baldin
Password:
Using DBIShell::dr::Pg engine

dbi:Pg:host=localhost;database=test:baldin>quit/
Для завершения любой команды используется косая черта /.

==GUI вам в помощь==
Следует признать, что программа с графическим пользовательским интерфейсом выглядит гораздо солиднее какой-то там командной строки. Об эффективности работы в случае необходимости показать, что занят важным делом, речь, естественно, не идет. Зачем один терминал, когда можно открыть кучу красивеньких окошечек с иконками? Конечно, PostgreSQL позволяет разговаривать с собой и через окна.

==PgAccess==
Когда обсуждается графический пользовательский интерфейс к PostgreSQL, тут же всплывает слово PgAccess (http://www.pgaccess.org/). PgAccess создан Константином Теодореску (Constantin Teodorescu) и имеет довольно длительную историю развития. На текущий момент разработка, похоже, заморожена. С другой стороны, «нет худа без добра»: новых версий тащить не надо – достаточно поставить то, что идет стандартно с вашим дистрибутивом:
> sudo apt-get install PgAccess
> PgAccess
Для того, чтобы подсоединиться к базе данных необходимо воспользоваться диалогом открытия соединения: Database -> Open. По умолчанию предполагается, что postmaster запущен на этом же компьютере (Host: localhost), и он «слушает» порт номер 5432 – если при установке PostgreSQL ничего специально не делалось, то так оно и есть. Далее требуется указать базу данных, к которой надо подсоединиться, пользователя и, если необходимо, пароль.

PgAccess явно что-то умеет.

PgAccess – это кросс-платформенный графический интерфейс к PostgreSQL написанный на чистом Tcl/Tk, и как следствие этого, работает везде, где этот инструментарий имеется (даже на «альтернативной» платформе). Размер дистрибутива по современным меркам крошечный: при установке все укладывается в 4 Мб.

В программе есть возможность создавать, редактировать и просматривать таблицы, запросы, представления, функции, пользователей, то есть довольно многое из того, что можно делать c помощью SQL. Плюс к этому можно создавать графические формы для ввода/просмотра данных, рисовать простые диаграммы и графики, просматривать картинки, сохраненные в базе данных. Так как программа написана на Tcl/Tk, то есть возможность писать свои скрипты, используя объекты, уже определенные в PgAccess.

Если хочется «сляпать» на скорую руку формочку, которую мож но запустить фактически где угодно после минимальной доводки, то PgAccess вполне может подойти для этого дела. В самом PgAccess масса ограничений и недостатков, но так как программа относительно небольшая, то ее можно доделать «по месту».

Информацию о созданных формах, запросах и тому подобных объектах PgAccess сохраняет непосредственно в базе данных, в таблицах, начинающихся с префикса pga_. Так что то, что сделано кем-то одним, будет доступно и всем пользователям базы.

Наличие PgAccess на машине, с моей точки зрения, поощряет нездоровое желание что-то «сляпать», а не сделать по-человечески. Так что работать с этим предметом надо осторожно, и если нет необходимости, то лучше убрать его от греха подальше. По мне, так pSQL гораздо удобнее и эффективнее, а самое главное – пользователи наведываются в БД гораздо реже.

==pgAdmin III==
Программа порадует вас заявлением, что она наиболее популярная и функциональная платформа администрирования и разработки для PostgreSQL, а также своим отсутствием в дистрибутиве Debian (Sarge), посему установка начнется с ее выкачивания. К счастью, на сайте проекта http://www.pgadmin.org/ можно найти сборки под множество дистрибутивов. Есть и специальный репозитарий для Debian – в /etc/apt/source.list добавляется строка:
deb [MIRROR URL]/pgadmin3/release/debian sarge pgadmin
где вместо [MIRROR URL] подставляется одно из официальных зеркал PostgreSQL, например: ftp://ftp.ru.PostgreSQL.org/pub/mirrors/pgSQL, и производится установка программы:
> sudo apt-get update
> sudo apt-get install pgadmin3
> pgadmin3
При этом скачивается около 7,5 Мб. После запуска можно убедиться, что программа выглядит вполне солидно.

pgAdmin III подробно объясняет что надо «сказать» чтобы создать выбранный объект.

Новое соединение создается через меню File Add server. Требуется указать Address (localhost для локальной машины), сделать краткое описание соединения (Description), выбрать базу данных (Maintenance DB) и пользователя. После подсоединения доступны все объекты, которыми может управлять текущий пользователь.

PgAdmin III – это продукт для администрирования и управления базами данных под управлением PostgreSQL и его потомков. PgAdmin III содержит в себе графический интерфейс для управления данными, SQL-редактор с графическим представлением EXPLAIN, имеет инструменты для создания и редактирования таблиц, умеет управляться с системой репликации Slony-I и многое другое, что действительно упрощает администрирование. И все-таки PgAdmin III не для пользователя. Пока нет понимания того, что происходит, не следует уповать на картинки.

Изначально pgAdmin разрабатывался под Windows, но на сегодня этот продукт является многоплатформенным решением и работает также под Linux, Mac OSX, FreeBSD и Solaris. В качестве графической библиотеки используется wxWidgets (http://www.wxwidgets.org).

Русский перевод интерфейса, в принципе, существует, но на текущий момент не поддерживается. С другой стороны, это прежде всего инструмент администрирования и управления данными. В любом случае, разработчики приветствуют новые и обновленные переводы.
==TOra==
TOra возникла благодаря тому, что Генри Джонсон (Henrik Johnson) не смог запустить VMWare с Windows в далеком 2000 году. В то же время ему хотелось иметь графическую утилиту для администрирования Oracle, подобную той, которой пользовались его друзья, так и не отошедшие от «окон». TOra – это toolkit for Oracle. Так было, но на сегодня (в том числе и вследствие того, что TOra написана с использованием библиотеки Qt3), также можно работать и с PostgreSQL. Кроме PostgreSQL, дополнительно поддерживается MySQL и все, что работает через ODBC.
<ref>Вследствие того, что PostgreSQL распространяется под лицензией BSD, имеется несколько
коммерческих продуктов, основанных на его коде, например, EnterpriseDB, Pervasive Postgres и SRA PowerGres.0</ref>

Установка и запуск TOra просты:
> sudo apt-get install TOra
> TOra
TOra предлагает диалог создания нового соединения сразу при старте. Требуется указать Connection рrovider (PostgreSQL), Username, Host (localhost), Port (5432) и DataBase.
Из-за прошлого программы, многие возможности TOra оказались привязаны к особенностям Oracle. В случае работы с PostgreSQL, TOra полезна прежде всего как браузер по SQL-объектам, SQL-терминал и изощренный SQL-редактор. Как и в случае pgAdmin III, TOra позволяет создавать и редактировать таблицы с помощью графических диалогов, но не владеет специфичными для PostgreSQL настройками.
TOra – это крепко «сбитый» программный продукт, который позволяет работать с разными реляционными СУБД в пределах одной программы.

==OpenOffice.org и SDBC==
OpenOffice.org – монстр, но ситуация на сегодня такая, что люди любят монстров, и ничего в обозримом будущем с этим не поделаешь.

OpenOffice + PostgreSQL.

Для прямого доступа из OpenOffice к PostgreSQL без промежуточного уровня в виде ODBC/JDBC драйверов разрабатывается драйвер PostgreSQL-sdbc. На сегодня в стандартной поставке OpenOffice.org этот пакет отсутствует.

Для установки необходимо скачать zip-архив этого драйвера с его домашней странички [http://dba.OpenOffice.org/drivers/PostgreSQL/index.html OpenOffice.org] и положить куда-нибудь у себя на диске не распаковывая (!). Далее, запустив OpenOffice, следует открыть диалог управления пакетами: Сервис Управление пакетами… и с помощью кнопки Добавить установить этот пакет. В моем случае после установки пришлось перезапустить OpenOffice.

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

Создать Базу данных Выбор базы данных, поставить галочку Подключиться к существующей базе данных и выбрать PostgreSQL. Далее при настройке соединения в следует ввести строчку вида:
dbname=”имя БД” host=”адрес сервера”
подставив вместо имя БД и адрес сервера имя предварительно созданной базы данных и адрес сервера, на котором «крутится» postmaster, например, dbname=test host=localhost. Далее, во вкладке Аутентификация пользователя необходимо ввести имя пользователя – затем можно протестировать соединение. Если тест прошел нормально, то можно продолжить и выполнить подключение.

Во время окончания действия мастера предлагается сохранить все, что проделано в ODB-файле (формат База данных OpenDocument). Затем это соединение можно будет выполнить простым открытием файла. Туда же сохраняется информация обо всех созданных формах, запросах и отчетах. Как конкретно создаются формы и отчеты – это совсем другая история и относится она не к PostgreSQL, а к OpenOffice.org (см.[[ PostgreSQL. ЧАСТЬ 1: Введение|LXF85:PostgreSQL]]).

При выборе таблиц легко видеть, что они в PostgreSQL разбиты на группы. Пользовательские таблицы по умолчанию находятся в группе public. В группах pg_catalog и informaion_schema представлена системная информация и статистика.

==Что выбрать?==
Естественно, мы рассмотрели далеко не все возможные программы общего назначения для работы с PostgreSQL, но даже из того, что рассмотрено, нельзя выбрать что-то одно. Каждая программа имеет свои особенности и преимущества. psql позволяет легко работать удаленно, OpenOffice.org удовлетворяет нашу любовь к монстрам, PgAdmin III содержит множество подсказок по делу, PgAccess удивляет своей интеграцией с TCL/Tk, а TOra – «просто красивая».

Я всегда выбирал psql, но это скорее всего связано со специфичностью решаемых мной задач. Я вполне могу представить себе ситуацию, когда наличие, например, TOra значительно облегчит жизнь. Ну и не следует забывать про данные, которые кто-то должен вводить. Если лень писать специальную программу (которую лучше все-таки написать), то OpenOffice.org поможет, особенно если вводить не вам.

==См.также==
* [[Азбука SQL]]
* [[SQL]]

==Примечания==
<references />

LXF86:PostgreSQL

2008-03-12T12:14:45Z

PonElA:

<<[[LXF86]]

'''PostgreSQL. ЧАСТЬ 2: Работа с базой'''

Проблема компьютеров в том, что они делают то, что вы сказали, а не то, что подумали. Поэтому запустить PostgreSQL недостаточно – нужно еще суметь договориться с ним на понятном языке. [[Балдин Евгений|Евгений Балдин]] открывает русско-машинный словарь...

:Это прибор, – сказал Корнеев безнадежно. – С ним работают...
::«Понедельник начинается в субботу»
==Работа с базой==
'''В''' прошлой части мы узнали, как создать базу данных и запустить postmaster. Теперь дело за малым: надо научиться сохранять данные и «доступаться» до них. Для этого следует договориться с postmaster – благо его «родной» язык довольно высокоуровневый.

Как и в предыдущей части, все рассматривается с точки зрения дистрибутива Debian (Sarge). При прочтении следует иметь это в виду.
{| class="standard"
!Год||Ревизия||Нововведения
|-
|1986||SQL-86, SQL-87|| Первая версия стандарта ANSI. Принят ISO в 1987 году. Стандартизация синтаксиса.
|-
|1989||SQL-89 || Стандартизован механизм ссылочной целостности.
|-
|1992||SQL-92 (SQL-2)||Множество нововведений. В отличие от предыдущих версий, где стандарт просто сертифицировал уже имеющиеся на рынке реляционных БД возможности, были заложены основы для развития языка. Введены три уровня соответствия стандарту Entry (начальный), Intermediate (промежуточный), Full (полный). Мало какая из баз данных поддерживает SQL-92 лучше, чем Entry.
|-
|1999 ||SQL:1999 (SQL-3) || Добавлены регулярные выражения, рекурсивные запросы, триггеры. Определена интеграция с объектно-ориентированным подходом. Вместо трех уровней соответствия введен набор свойств (features).
|-
|2003||SQL:2003 ||Стандартизованы XML-зависимые нововведения, интервальные функции (window functions), стандартные последовательности и столбцы с автоматически генерируемыми значениями.
|}

==SQL==
В качестве языка общения с реляционными базами данных в подавляющем большинстве случаев используется [[SQL]]. Изначально эти три буквы были сокращением фразы Structured Query Language (язык структурированных запросов). Сейчас, когда язык стал стандартом,SQL уже не является аббревиатурой – это обычное название, которое произносится как «эс-кью-эл». Несмотря на это, даже англоязычные специалисты по прежнему часто называют SQL «сиквел». По-русски также часто говорят «эс-ку-эль».

У этого языка есть недостатки, приводящие к тому, что в реальности SQL дополняется различными расширениями. Кстати, сам Кодд, «отец» реляционных баз данных, считал SQL неудачной реализацией его теории. Но на сегодня это мощный открытый промышленный стандарт, который позволяет решать множество типовых задач по созданию, модификации и управлению данными – он есть здесь и сейчас.

За время своего существования SQL претерпел несколько ревизий. Основные вехи в истории стандарта перечислены в таблице.
Степень соответствия PostgreSQL стандарту SQL:2003 подробно рассмотрена в Приложении D (Appendix D. SQL Conformance) стандартной документации.

Там же есть и простейший учебник, и исчерпывающий справочник по SQL. Существует море литературы, в которой подробно и не очень рассказывается, что же это за «зверь такой» – SQL. Необходимый для «вхождения в технологию» минимум настолько прост, что основы изучаются в пределах одного дня вдумчивого чтения учебника.

Для того, чтобы куда-то сохранить данные, необходимо создать«хранилище» – таблицу/таблицы:
CREATE TABLE fiodata (id int,fio text)
CREATE TABLE phonedata (id int,number text)
Теперь можно добавлять данные:
INSERT INTO fiodata VALUES (1,’Иванов И.П.’)
INSERT INTO phonedata VALUES (1,’555-32-23’)
и так далее. Мы создали две обычных таблицы «без наворотов»: в одной хранятся имена, а в другой – телефоны. Сопоставление телефонов именам происходит через поля id. Почему так? На одно имя может быть заведено несколько телефонов, а на одном телефоне может «сидеть» несколько человек.

Теперь надо извлечь данные, и в этом нам поможет оператор SELECT. Собственно говоря, пользователю, кроме этого оператора, больше ничего знать и не надо – все выборки делаются с его помощью. Выведем все имена и соответствующие им телефоны:
SELECT fio, number
FROM fiodata,phonedata WHERE fiodata.id=phonedata.id
SQL, очевидно, заслуживает большего, чем это «микровведение», и его, в любом случае, придется изучать тем, кто реально хочет заниматься базами данных – то есть от книжек никуда не денешься. А если подходить к делу серьезно, то кроме описания SQL следует изучить и основы реляционных баз данных того же К.Дж. Дейта (C.J. Date) – но это уже совсем другая история.

==Командная строка==
Когда набирается текст, а SQL – это именно текст, то лучше, чтобы ничего вокруг не отвлекало. Надежная, «толстая» и дешевая связь – вещь хорошая, только вот случается она не всегда, так что командная строка оказывается вне конкуренции.

==psql==

Вместе с пакетом postgresql-client поставляется утилита psql – интерактивная оболочка для «разговоров» с PostgreSQL. Она же – лучший инструмент для администрирования.

Окно psql.

Пусть существует база данных test, в которой заведены таблицы fiodata и phonedata, описанные в предыдущем разделе. Подсоединимся к базе и что-нибудь «спросим» у нее:
> psql test
Добро пожаловать в pSQL 7.4.7 – Интерактивный Терминал PostgreSQL.
Наберите: \copyright для условий распространения
'''\h''' для подсказки по SQL командам
'''\?''' для подсказки по внутренним slash-командам (\команда)
'''\g''' или “;” для завершения и выполнения запроса
'''\q''' для выхода

test=> SELECT fio, number
test-> FROM fiodata,phonedata WHERE fiodata.id=phonedata.id;
fio | number
-------------+----------------
Иванов И.П. | 555-32-23
Балдин Е.М. | 555-41-37
Балдин Е.М. | (+7)5559323919
(записей: 3)

Если хочется подсоединиться к серверу на другой машине, то нужно указать имя машины после ключа -h. Ключ -U позволяет указать имя пользователя.
{{Врезка|right|Ширина=200px
|Заголовок=Скорая помощь
|Содержание=После первого запуска PgAccess необходимо настроить шрифты:

Database->Preferences->Look & Feel.

Логика их выбора по умолчанию не совсем, с моей точки зрения,адекватна, с другой стороны – при желании это настраивается.}}

psql передает SQL-команды на сервер. Обратите внимание, что для завершения SQL-команды используется точка с запятой – ;.

Как и всякая человеко-ориентированная оболочка, pSQL использует библиотеку Readline. Это означает наличие стандартных горячих emacs-подобных комбинаций символов для общепринятого редактирования ввода командной строки, в том числе и завершение SQL-команд по Tab. По клавише Tab завершаются не только SQL-команды, но и названия таблиц и имена колонок, если это возможно.

psql поддерживает историю команд, которая сохраняется в .pSQL_history. Это также особенность библиотеки Readline. Полезным является интерактивный поиск по истории команд, который вызывается с помощью комбинации C^r.

Кроме команд SQL, psql имеет набор собственных специальных команд. Все такие команды начинаются с обратной косой черты \. Число спецкоманд довольно обширно и полное их описание можно распечатать, выполнив команду man pSQL. Далее будет перечислены наиболее интересные из них:

*'''\q''' Закончить работу с pSQL. Выйти из оболочки.
*'''\?''' Вывести справку по имеющимся спец-командам.
*'''\h''' [SQL-команда] Вывести помощь по запрашиваемой SQL-команде в форме Бэкуса-Наура (Backus Naur Form). SQL-команда может состоять из нескольких слов. При исполнении \h без аргумента выводится список доступных SQL-команд.
*'''\!''' [shell-команда] Запустить командный интерпретатор и выполнить команду оболочки.
*'''\i''' «файл» Прочитать текстовый файл и выполнить имеющиеся в нем команды. Удобно для нетривиальных операций.

Имя файла с командами можно передать при запуске psql посредством ключа -f. В этом случае после чтения и исполнения всех команд psql автоматически прекращает работу.
*'''\o''' [«файл»] Сохранить результаты выполнения будущих команд в файл. Если аргумент отсутствует, то вывод переключается на терминал. psql имеет набор команд, которые позволяют сформировать вывод в удобном для пользователя виде.

Имя файла, в котором следует сохранить результаты, также можно передать при запуске psql с помощью ключика -o. Этот ключ удобно применять совместно с ключом -f.
*'''d''' [«регулярное выражение»] Вывести структуру объекта. Годится для таблицы (table), представления (view), индекса (indexes) или последовательности (sequences). Список объектов можно получить, добавив первую букву названия объекта t, v, i, s к команде \d.

В дополнение к вышесказанному, psql поддерживает простейший механизм присваивания значений собственным переменным и их интерполяции в SQL-запросах:
test=> \set proba ‘phonedata’
test=> select * from :proba;
id | number
----+----------------
2 | 555-41-37
2 | (+7)5559323919
1 | 555-32-23
(записей: 3)

Следует учитывать, что интерполяция переменных не работает, если переменная используется внутри SQL-строки. В любом случае, хоть какое-то подспорье.

==gql-shell==
Небольшая psql-подобная оболочка, написанная одним человеком. Разработка заморожена. Естественно, она не обладает всеми возможностями psql, зато может подсоединяться и «разговаривать» не только с PostgreSQL. Для подсоединения к базе данных используется библиотека GQL (Generic C++ SQL Library). Для работы с PostgreSQL необходимо установить драйвер:
> sudo apt-get install gql-shell
> sudo apt-get install libgql-driver-0.5-pg
> gql-shell pg:test
Welcome to gql-shell, the interactive SQL terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

test=>

==dbishell==
dbishell – интерактивная оболочка на основе Perl::DBI. Как и gql-shell, поддерживает не только PostgreSQL. dbishell представляет из себя скрипт на Perl и занимает при установке чуть больше 150 Кб.
> sudo apt-get install dbishell
> dbishell --driver Pg --dsn host=localhost\;database=test --user baldin
Password:
Using DBIShell::dr::Pg engine

dbi:Pg:host=localhost;database=test:baldin>quit/
Для завершения любой команды используется косая черта /.

==GUI вам в помощь==
Следует признать, что программа с графическим пользовательским интерфейсом выглядит гораздо солиднее какой-то там командной строки. Об эффективности работы в случае необходимости показать, что занят важным делом, речь, естественно, не идет. Зачем один терминал, когда можно открыть кучу красивеньких окошечек с иконками? Конечно, PostgreSQL позволяет разговаривать с собой и через окна.

==PgAccess==
Когда обсуждается графический пользовательский интерфейс к PostgreSQL, тут же всплывает слово PgAccess (http://www.pgaccess.org/). PgAccess создан Константином Теодореску (Constantin Teodorescu) и имеет довольно длительную историю развития. На текущий момент разработка, похоже, заморожена. С другой стороны, «нет худа без добра»: новых версий тащить не надо – достаточно поставить то, что идет стандартно с вашим дистрибутивом:
> sudo apt-get install PgAccess
> PgAccess
Для того, чтобы подсоединиться к базе данных необходимо воспользоваться диалогом открытия соединения: Database -> Open. По умолчанию предполагается, что postmaster запущен на этом же компьютере (Host: localhost), и он «слушает» порт номер 5432 – если при установке PostgreSQL ничего специально не делалось, то так оно и есть. Далее требуется указать базу данных, к которой надо подсоединиться, пользователя и, если необходимо, пароль.

PgAccess явно что-то умеет.

PgAccess – это кросс-платформенный графический интерфейс к PostgreSQL написанный на чистом Tcl/Tk, и как следствие этого, работает везде, где этот инструментарий имеется (даже на «альтернативной» платформе). Размер дистрибутива по современным меркам крошечный: при установке все укладывается в 4 Мб.

В программе есть возможность создавать, редактировать и просматривать таблицы, запросы, представления, функции, пользователей, то есть довольно многое из того, что можно делать c помощью SQL. Плюс к этому можно создавать графические формы для ввода/просмотра данных, рисовать простые диаграммы и графики, просматривать картинки, сохраненные в базе данных. Так как программа написана на Tcl/Tk, то есть возможность писать свои скрипты, используя объекты, уже определенные в PgAccess.

Если хочется «сляпать» на скорую руку формочку, которую мож но запустить фактически где угодно после минимальной доводки, то PgAccess вполне может подойти для этого дела. В самом PgAccess масса ограничений и недостатков, но так как программа относительно небольшая, то ее можно доделать «по месту».

Информацию о созданных формах, запросах и тому подобных объектах PgAccess сохраняет непосредственно в базе данных, в таблицах, начинающихся с префикса pga_. Так что то, что сделано кем-то одним, будет доступно и всем пользователям базы.

Наличие PgAccess на машине, с моей точки зрения, поощряет нездоровое желание что-то «сляпать», а не сделать по-человечески. Так что работать с этим предметом надо осторожно, и если нет необходимости, то лучше убрать его от греха подальше. По мне, так pSQL гораздо удобнее и эффективнее, а самое главное – пользователи наведываются в БД гораздо реже.

==pgAdmin III==
Программа порадует вас заявлением, что она наиболее популярная и функциональная платформа администрирования и разработки для PostgreSQL, а также своим отсутствием в дистрибутиве Debian (Sarge), посему установка начнется с ее выкачивания. К счастью, на сайте проекта http://www.pgadmin.org/ можно найти сборки под множество дистрибутивов. Есть и специальный репозитарий для Debian – в /etc/apt/source.list добавляется строка:
deb [MIRROR URL]/pgadmin3/release/debian sarge pgadmin
где вместо [MIRROR URL] подставляется одно из официальных зеркал PostgreSQL, например: ftp://ftp.ru.PostgreSQL.org/pub/mirrors/pgSQL, и производится установка программы:
> sudo apt-get update
> sudo apt-get install pgadmin3
> pgadmin3
При этом скачивается около 7,5 Мб. После запуска можно убедиться, что программа выглядит вполне солидно.

pgAdmin III подробно объясняет что надо «сказать» чтобы создать выбранный объект.

Новое соединение создается через меню File Add server. Требуется указать Address (localhost для локальной машины), сделать краткое описание соединения (Description), выбрать базу данных (Maintenance DB) и пользователя. После подсоединения доступны все объекты, которыми может управлять текущий пользователь.

PgAdmin III – это продукт для администрирования и управления базами данных под управлением PostgreSQL и его потомков. PgAdmin III содержит в себе графический интерфейс для управления данными, SQL-редактор с графическим представлением EXPLAIN, имеет инструменты для создания и редактирования таблиц, умеет управляться с системой репликации Slony-I и многое другое, что действительно упрощает администрирование. И все-таки PgAdmin III не для пользователя. Пока нет понимания того, что происходит, не следует уповать на картинки.

Изначально pgAdmin разрабатывался под Windows, но на сегодня этот продукт является многоплатформенным решением и работает также под Linux, Mac OSX, FreeBSD и Solaris. В качестве графической библиотеки используется wxWidgets (http://www.wxwidgets.org).

Русский перевод интерфейса, в принципе, существует, но на текущий момент не поддерживается. С другой стороны, это прежде всего инструмент администрирования и управления данными. В любом случае, разработчики приветствуют новые и обновленные переводы.
==TOra==
TOra возникла благодаря тому, что Генри Джонсон (Henrik Johnson) не смог запустить VMWare с Windows в далеком 2000 году. В то же время ему хотелось иметь графическую утилиту для администрирования Oracle, подобную той, которой пользовались его друзья, так и не отошедшие от «окон». TOra – это toolkit for Oracle. Так было, но на сегодня (в том числе и вследствие того, что TOra написана с использованием библиотеки Qt3), также можно работать и с PostgreSQL. Кроме PostgreSQL, дополнительно поддерживается MySQL и все, что работает через ODBC.
<ref>Вследствие того, что PostgreSQL распространяется под лицензией BSD, имеется несколько
коммерческих продуктов, основанных на его коде, например, EnterpriseDB, Pervasive Postgres и SRA PowerGres.0</ref>

Установка и запуск TOra просты:
> sudo apt-get install TOra
> TOra
TOra предлагает диалог создания нового соединения сразу при старте. Требуется указать Connection рrovider (PostgreSQL), Username, Host (localhost), Port (5432) и DataBase.
Из-за прошлого программы, многие возможности TOra оказались привязаны к особенностям Oracle. В случае работы с PostgreSQL, TOra полезна прежде всего как браузер по SQL-объектам, SQL-терминал и изощренный SQL-редактор. Как и в случае pgAdmin III, TOra позволяет создавать и редактировать таблицы с помощью графических диалогов, но не владеет специфичными для PostgreSQL настройками.
TOra – это крепко «сбитый» программный продукт, который позволяет работать с разными реляционными СУБД в пределах одной программы.

==OpenOffice.org и SDBC==
OpenOffice.org – монстр, но ситуация на сегодня такая, что люди любят монстров, и ничего в обозримом будущем с этим не поделаешь.

OpenOffice + PostgreSQL.

Для прямого доступа из OpenOffice к PostgreSQL без промежуточного уровня в виде ODBC/JDBC драйверов разрабатывается драйвер PostgreSQL-sdbc. На сегодня в стандартной поставке OpenOffice.org этот пакет отсутствует.

Для установки необходимо скачать zip-архив этого драйвера с его домашней странички [http://dba.OpenOffice.org/drivers/PostgreSQL/index.html OpenOffice.org] и положить куда-нибудь у себя на диске не распаковывая (!). Далее, запустив OpenOffice, следует открыть диалог управления пакетами: Сервис Управление пакетами… и с помощью кнопки Добавить установить этот пакет. В моем случае после установки пришлось перезапустить OpenOffice.

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

Создать Базу данных Выбор базы данных, поставить галочку Подключиться к существующей базе данных и выбрать PostgreSQL. Далее при настройке соединения в следует ввести строчку вида:
dbname=”имя БД” host=”адрес сервера”
подставив вместо имя БД и адрес сервера имя предварительно созданной базы данных и адрес сервера, на котором «крутится» postmaster, например, dbname=test host=localhost. Далее, во вкладке Аутентификация пользователя необходимо ввести имя пользователя – затем можно протестировать соединение. Если тест прошел нормально, то можно продолжить и выполнить подключение.

Во время окончания действия мастера предлагается сохранить все, что проделано в ODB-файле (формат База данных OpenDocument). Затем это соединение можно будет выполнить простым открытием файла. Туда же сохраняется информация обо всех созданных формах, запросах и отчетах. Как конкретно создаются формы и отчеты – это совсем другая история и относится она не к PostgreSQL, а к OpenOffice.org (см.[[ PostgreSQL. ЧАСТЬ 1: Введение|LXF85 ЧАСТЬ 1]]).

При выборе таблиц легко видеть, что они в PostgreSQL разбиты на группы. Пользовательские таблицы по умолчанию находятся в группе public. В группах pg_catalog и informaion_schema представлена системная информация и статистика.

==Что выбрать?==
Естественно, мы рассмотрели далеко не все возможные программы общего назначения для работы с PostgreSQL, но даже из того, что рассмотрено, нельзя выбрать что-то одно. Каждая программа имеет свои особенности и преимущества. psql позволяет легко работать удаленно, OpenOffice.org удовлетворяет нашу любовь к монстрам, PgAdmin III содержит множество подсказок по делу, PgAccess удивляет своей интеграцией с TCL/Tk, а TOra – «просто красивая».

Я всегда выбирал psql, но это скорее всего связано со специфичностью решаемых мной задач. Я вполне могу представить себе ситуацию, когда наличие, например, TOra значительно облегчит жизнь. Ну и не следует забывать про данные, которые кто-то должен вводить. Если лень писать специальную программу (которую лучше все-таки написать), то OpenOffice.org поможет, особенно если вводить не вам.

==См.также==
* [[Азбука SQL]]
* [[SQL]]

==Примечания==
<references />

LXF86:PostgreSQL

2008-03-12T12:13:41Z

PonElA: Новая: <<LXF86 ''' PostgreSQL. ЧАСТЬ 2: Работа с базой''' Проблема компьютеров в том, что они делают то, что вы сказали, ...

<<[[LXF86]]
'''
PostgreSQL. ЧАСТЬ 2: Работа с базой'''

Проблема компьютеров в том, что они делают то, что вы сказали, а не то, что подумали. Поэтому запустить PostgreSQL недостаточно – нужно еще суметь договориться с ним на понятном языке. [[Балдин Евгений|Евгений Балдин]] открывает русско-машинный словарь...

:Это прибор, – сказал Корнеев безнадежно. – С ним работают...
::«Понедельник начинается в субботу»
==Работа с базой==
'''В''' прошлой части мы узнали, как создать базу данных и запустить postmaster. Теперь дело за малым: надо научиться сохранять данные и «доступаться» до них. Для этого следует договориться с postmaster – благо его «родной» язык довольно высокоуровневый.

Как и в предыдущей части, все рассматривается с точки зрения дистрибутива Debian (Sarge). При прочтении следует иметь это в виду.
{| class="standard"
!Год||Ревизия||Нововведения
|-
|1986||SQL-86, SQL-87|| Первая версия стандарта ANSI. Принят ISO в 1987 году. Стандартизация синтаксиса.
|-
|1989||SQL-89 || Стандартизован механизм ссылочной целостности.
|-
|1992||SQL-92 (SQL-2)||Множество нововведений. В отличие от предыдущих версий, где стандарт просто сертифицировал уже имеющиеся на рынке реляционных БД возможности, были заложены основы для развития языка. Введены три уровня соответствия стандарту Entry (начальный), Intermediate (промежуточный), Full (полный). Мало какая из баз данных поддерживает SQL-92 лучше, чем Entry.
|-
|1999 ||SQL:1999 (SQL-3) || Добавлены регулярные выражения, рекурсивные запросы, триггеры. Определена интеграция с объектно-ориентированным подходом. Вместо трех уровней соответствия введен набор свойств (features).
|-
|2003||SQL:2003 ||Стандартизованы XML-зависимые нововведения, интервальные функции (window functions), стандартные последовательности и столбцы с автоматически генерируемыми значениями.
|}

==SQL==
В качестве языка общения с реляционными базами данных в подавляющем большинстве случаев используется [[SQL]]. Изначально эти три буквы были сокращением фразы Structured Query Language (язык структурированных запросов). Сейчас, когда язык стал стандартом,SQL уже не является аббревиатурой – это обычное название, которое произносится как «эс-кью-эл». Несмотря на это, даже англоязычные специалисты по прежнему часто называют SQL «сиквел». По-русски также часто говорят «эс-ку-эль».

У этого языка есть недостатки, приводящие к тому, что в реальности SQL дополняется различными расширениями. Кстати, сам Кодд, «отец» реляционных баз данных, считал SQL неудачной реализацией его теории. Но на сегодня это мощный открытый промышленный стандарт, который позволяет решать множество типовых задач по созданию, модификации и управлению данными – он есть здесь и сейчас.

За время своего существования SQL претерпел несколько ревизий. Основные вехи в истории стандарта перечислены в таблице.
Степень соответствия PostgreSQL стандарту SQL:2003 подробно рассмотрена в Приложении D (Appendix D. SQL Conformance) стандартной документации.

Там же есть и простейший учебник, и исчерпывающий справочник по SQL. Существует море литературы, в которой подробно и не очень рассказывается, что же это за «зверь такой» – SQL. Необходимый для «вхождения в технологию» минимум настолько прост, что основы изучаются в пределах одного дня вдумчивого чтения учебника.

Для того, чтобы куда-то сохранить данные, необходимо создать«хранилище» – таблицу/таблицы:
CREATE TABLE fiodata (id int,fio text)
CREATE TABLE phonedata (id int,number text)
Теперь можно добавлять данные:
INSERT INTO fiodata VALUES (1,’Иванов И.П.’)
INSERT INTO phonedata VALUES (1,’555-32-23’)
и так далее. Мы создали две обычных таблицы «без наворотов»: в одной хранятся имена, а в другой – телефоны. Сопоставление телефонов именам происходит через поля id. Почему так? На одно имя может быть заведено несколько телефонов, а на одном телефоне может «сидеть» несколько человек.

Теперь надо извлечь данные, и в этом нам поможет оператор SELECT. Собственно говоря, пользователю, кроме этого оператора, больше ничего знать и не надо – все выборки делаются с его помощью. Выведем все имена и соответствующие им телефоны:
SELECT fio, number
FROM fiodata,phonedata WHERE fiodata.id=phonedata.id
SQL, очевидно, заслуживает большего, чем это «микровведение», и его, в любом случае, придется изучать тем, кто реально хочет заниматься базами данных – то есть от книжек никуда не денешься. А если подходить к делу серьезно, то кроме описания SQL следует изучить и основы реляционных баз данных того же К.Дж. Дейта (C.J. Date) – но это уже совсем другая история.

==Командная строка==
Когда набирается текст, а SQL – это именно текст, то лучше, чтобы ничего вокруг не отвлекало. Надежная, «толстая» и дешевая связь – вещь хорошая, только вот случается она не всегда, так что командная строка оказывается вне конкуренции.

==psql==

Вместе с пакетом postgresql-client поставляется утилита psql – интерактивная оболочка для «разговоров» с PostgreSQL. Она же – лучший инструмент для администрирования.

Окно psql.

Пусть существует база данных test, в которой заведены таблицы fiodata и phonedata, описанные в предыдущем разделе. Подсоединимся к базе и что-нибудь «спросим» у нее:
> psql test
Добро пожаловать в pSQL 7.4.7 – Интерактивный Терминал PostgreSQL.
Наберите: \copyright для условий распространения
'''\h''' для подсказки по SQL командам
'''\?''' для подсказки по внутренним slash-командам (\команда)
'''\g''' или “;” для завершения и выполнения запроса
'''\q''' для выхода

test=> SELECT fio, number
test-> FROM fiodata,phonedata WHERE fiodata.id=phonedata.id;
fio | number
-------------+----------------
Иванов И.П. | 555-32-23
Балдин Е.М. | 555-41-37
Балдин Е.М. | (+7)5559323919
(записей: 3)

Если хочется подсоединиться к серверу на другой машине, то нужно указать имя машины после ключа -h. Ключ -U позволяет указать имя пользователя.
{{Врезка|right|Ширина=200px
|Заголовок=Скорая помощь
|Содержание=После первого запуска PgAccess необходимо настроить шрифты:

Database->Preferences->Look & Feel.

Логика их выбора по умолчанию не совсем, с моей точки зрения,адекватна, с другой стороны – при желании это настраивается.}}

psql передает SQL-команды на сервер. Обратите внимание, что для завершения SQL-команды используется точка с запятой – ;.

Как и всякая человеко-ориентированная оболочка, pSQL использует библиотеку Readline. Это означает наличие стандартных горячих emacs-подобных комбинаций символов для общепринятого редактирования ввода командной строки, в том числе и завершение SQL-команд по Tab. По клавише Tab завершаются не только SQL-команды, но и названия таблиц и имена колонок, если это возможно.

psql поддерживает историю команд, которая сохраняется в .pSQL_history. Это также особенность библиотеки Readline. Полезным является интерактивный поиск по истории команд, который вызывается с помощью комбинации C^r.

Кроме команд SQL, psql имеет набор собственных специальных команд. Все такие команды начинаются с обратной косой черты \. Число спецкоманд довольно обширно и полное их описание можно распечатать, выполнив команду man pSQL. Далее будет перечислены наиболее интересные из них:

*'''\q''' Закончить работу с pSQL. Выйти из оболочки.
*'''\?''' Вывести справку по имеющимся спец-командам.
*'''\h''' [SQL-команда] Вывести помощь по запрашиваемой SQL-команде в форме Бэкуса-Наура (Backus Naur Form). SQL-команда может состоять из нескольких слов. При исполнении \h без аргумента выводится список доступных SQL-команд.
*'''\!''' [shell-команда] Запустить командный интерпретатор и выполнить команду оболочки.
*'''\i''' «файл» Прочитать текстовый файл и выполнить имеющиеся в нем команды. Удобно для нетривиальных операций.

Имя файла с командами можно передать при запуске psql посредством ключа -f. В этом случае после чтения и исполнения всех команд psql автоматически прекращает работу.
*'''\o''' [«файл»] Сохранить результаты выполнения будущих команд в файл. Если аргумент отсутствует, то вывод переключается на терминал. psql имеет набор команд, которые позволяют сформировать вывод в удобном для пользователя виде.

Имя файла, в котором следует сохранить результаты, также можно передать при запуске psql с помощью ключика -o. Этот ключ удобно применять совместно с ключом -f.
*'''d''' [«регулярное выражение»] Вывести структуру объекта. Годится для таблицы (table), представления (view), индекса (indexes) или последовательности (sequences). Список объектов можно получить, добавив первую букву названия объекта t, v, i, s к команде \d.

В дополнение к вышесказанному, psql поддерживает простейший механизм присваивания значений собственным переменным и их интерполяции в SQL-запросах:
test=> \set proba ‘phonedata’
test=> select * from :proba;
id | number
----+----------------
2 | 555-41-37
2 | (+7)5559323919
1 | 555-32-23
(записей: 3)

Следует учитывать, что интерполяция переменных не работает, если переменная используется внутри SQL-строки. В любом случае, хоть какое-то подспорье.

==gql-shell==
Небольшая psql-подобная оболочка, написанная одним человеком. Разработка заморожена. Естественно, она не обладает всеми возможностями psql, зато может подсоединяться и «разговаривать» не только с PostgreSQL. Для подсоединения к базе данных используется библиотека GQL (Generic C++ SQL Library). Для работы с PostgreSQL необходимо установить драйвер:
> sudo apt-get install gql-shell
> sudo apt-get install libgql-driver-0.5-pg
> gql-shell pg:test
Welcome to gql-shell, the interactive SQL terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

test=>

==dbishell==
dbishell – интерактивная оболочка на основе Perl::DBI. Как и gql-shell, поддерживает не только PostgreSQL. dbishell представляет из себя скрипт на Perl и занимает при установке чуть больше 150 Кб.
> sudo apt-get install dbishell
> dbishell --driver Pg --dsn host=localhost\;database=test --user baldin
Password:
Using DBIShell::dr::Pg engine

dbi:Pg:host=localhost;database=test:baldin>quit/
Для завершения любой команды используется косая черта /.

==GUI вам в помощь==
Следует признать, что программа с графическим пользовательским интерфейсом выглядит гораздо солиднее какой-то там командной строки. Об эффективности работы в случае необходимости показать, что занят важным делом, речь, естественно, не идет. Зачем один терминал, когда можно открыть кучу красивеньких окошечек с иконками? Конечно, PostgreSQL позволяет разговаривать с собой и через окна.

==PgAccess==
Когда обсуждается графический пользовательский интерфейс к PostgreSQL, тут же всплывает слово PgAccess (http://www.pgaccess.org/). PgAccess создан Константином Теодореску (Constantin Teodorescu) и имеет довольно длительную историю развития. На текущий момент разработка, похоже, заморожена. С другой стороны, «нет худа без добра»: новых версий тащить не надо – достаточно поставить то, что идет стандартно с вашим дистрибутивом:
> sudo apt-get install PgAccess
> PgAccess
Для того, чтобы подсоединиться к базе данных необходимо воспользоваться диалогом открытия соединения: Database -> Open. По умолчанию предполагается, что postmaster запущен на этом же компьютере (Host: localhost), и он «слушает» порт номер 5432 – если при установке PostgreSQL ничего специально не делалось, то так оно и есть. Далее требуется указать базу данных, к которой надо подсоединиться, пользователя и, если необходимо, пароль.

PgAccess явно что-то умеет.

PgAccess – это кросс-платформенный графический интерфейс к PostgreSQL написанный на чистом Tcl/Tk, и как следствие этого, работает везде, где этот инструментарий имеется (даже на «альтернативной» платформе). Размер дистрибутива по современным меркам крошечный: при установке все укладывается в 4 Мб.

В программе есть возможность создавать, редактировать и просматривать таблицы, запросы, представления, функции, пользователей, то есть довольно многое из того, что можно делать c помощью SQL. Плюс к этому можно создавать графические формы для ввода/просмотра данных, рисовать простые диаграммы и графики, просматривать картинки, сохраненные в базе данных. Так как программа написана на Tcl/Tk, то есть возможность писать свои скрипты, используя объекты, уже определенные в PgAccess.

Если хочется «сляпать» на скорую руку формочку, которую мож но запустить фактически где угодно после минимальной доводки, то PgAccess вполне может подойти для этого дела. В самом PgAccess масса ограничений и недостатков, но так как программа относительно небольшая, то ее можно доделать «по месту».

Информацию о созданных формах, запросах и тому подобных объектах PgAccess сохраняет непосредственно в базе данных, в таблицах, начинающихся с префикса pga_. Так что то, что сделано кем-то одним, будет доступно и всем пользователям базы.

Наличие PgAccess на машине, с моей точки зрения, поощряет нездоровое желание что-то «сляпать», а не сделать по-человечески. Так что работать с этим предметом надо осторожно, и если нет необходимости, то лучше убрать его от греха подальше. По мне, так pSQL гораздо удобнее и эффективнее, а самое главное – пользователи наведываются в БД гораздо реже.

==pgAdmin III==
Программа порадует вас заявлением, что она наиболее популярная и функциональная платформа администрирования и разработки для PostgreSQL, а также своим отсутствием в дистрибутиве Debian (Sarge), посему установка начнется с ее выкачивания. К счастью, на сайте проекта http://www.pgadmin.org/ можно найти сборки под множество дистрибутивов. Есть и специальный репозитарий для Debian – в /etc/apt/source.list добавляется строка:
deb [MIRROR URL]/pgadmin3/release/debian sarge pgadmin
где вместо [MIRROR URL] подставляется одно из официальных зеркал PostgreSQL, например: ftp://ftp.ru.PostgreSQL.org/pub/mirrors/pgSQL, и производится установка программы:
> sudo apt-get update
> sudo apt-get install pgadmin3
> pgadmin3
При этом скачивается около 7,5 Мб. После запуска можно убедиться, что программа выглядит вполне солидно.

pgAdmin III подробно объясняет что надо «сказать» чтобы создать выбранный объект.

Новое соединение создается через меню File Add server. Требуется указать Address (localhost для локальной машины), сделать краткое описание соединения (Description), выбрать базу данных (Maintenance DB) и пользователя. После подсоединения доступны все объекты, которыми может управлять текущий пользователь.

PgAdmin III – это продукт для администрирования и управления базами данных под управлением PostgreSQL и его потомков. PgAdmin III содержит в себе графический интерфейс для управления данными, SQL-редактор с графическим представлением EXPLAIN, имеет инструменты для создания и редактирования таблиц, умеет управляться с системой репликации Slony-I и многое другое, что действительно упрощает администрирование. И все-таки PgAdmin III не для пользователя. Пока нет понимания того, что происходит, не следует уповать на картинки.

Изначально pgAdmin разрабатывался под Windows, но на сегодня этот продукт является многоплатформенным решением и работает также под Linux, Mac OSX, FreeBSD и Solaris. В качестве графической библиотеки используется wxWidgets (http://www.wxwidgets.org).

Русский перевод интерфейса, в принципе, существует, но на текущий момент не поддерживается. С другой стороны, это прежде всего инструмент администрирования и управления данными. В любом случае, разработчики приветствуют новые и обновленные переводы.
==TOra==
TOra возникла благодаря тому, что Генри Джонсон (Henrik Johnson) не смог запустить VMWare с Windows в далеком 2000 году. В то же время ему хотелось иметь графическую утилиту для администрирования Oracle, подобную той, которой пользовались его друзья, так и не отошедшие от «окон». TOra – это toolkit for Oracle. Так было, но на сегодня (в том числе и вследствие того, что TOra написана с использованием библиотеки Qt3), также можно работать и с PostgreSQL. Кроме PostgreSQL, дополнительно поддерживается MySQL и все, что работает через ODBC.
<ref>Вследствие того, что PostgreSQL распространяется под лицензией BSD, имеется несколько
коммерческих продуктов, основанных на его коде, например, EnterpriseDB, Pervasive Postgres и SRA PowerGres.0</ref>

Установка и запуск TOra просты:
> sudo apt-get install TOra
> TOra
TOra предлагает диалог создания нового соединения сразу при старте. Требуется указать Connection рrovider (PostgreSQL), Username, Host (localhost), Port (5432) и DataBase.
Из-за прошлого программы, многие возможности TOra оказались привязаны к особенностям Oracle. В случае работы с PostgreSQL, TOra полезна прежде всего как браузер по SQL-объектам, SQL-терминал и изощренный SQL-редактор. Как и в случае pgAdmin III, TOra позволяет создавать и редактировать таблицы с помощью графических диалогов, но не владеет специфичными для PostgreSQL настройками.
TOra – это крепко «сбитый» программный продукт, который позволяет работать с разными реляционными СУБД в пределах одной программы.

==OpenOffice.org и SDBC==
OpenOffice.org – монстр, но ситуация на сегодня такая, что люди любят монстров, и ничего в обозримом будущем с этим не поделаешь.

OpenOffice + PostgreSQL.

Для прямого доступа из OpenOffice к PostgreSQL без промежуточного уровня в виде ODBC/JDBC драйверов разрабатывается драйвер PostgreSQL-sdbc. На сегодня в стандартной поставке OpenOffice.org этот пакет отсутствует.

Для установки необходимо скачать zip-архив этого драйвера с его домашней странички [http://dba.OpenOffice.org/drivers/PostgreSQL/index.html OpenOffice.org] и положить куда-нибудь у себя на диске не распаковывая (!). Далее, запустив OpenOffice, следует открыть диалог управления пакетами: Сервис Управление пакетами… и с помощью кнопки Добавить установить этот пакет. В моем случае после установки пришлось перезапустить OpenOffice.

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

Создать Базу данных Выбор базы данных, поставить галочку Подключиться к существующей базе данных и выбрать PostgreSQL. Далее при настройке соединения в следует ввести строчку вида:
dbname=”имя БД” host=”адрес сервера”
подставив вместо имя БД и адрес сервера имя предварительно созданной базы данных и адрес сервера, на котором «крутится» postmaster, например, dbname=test host=localhost. Далее, во вкладке Аутентификация пользователя необходимо ввести имя пользователя – затем можно протестировать соединение. Если тест прошел нормально, то можно продолжить и выполнить подключение.

Во время окончания действия мастера предлагается сохранить все, что проделано в ODB-файле (формат База данных OpenDocument). Затем это соединение можно будет выполнить простым открытием файла. Туда же сохраняется информация обо всех созданных формах, запросах и отчетах. Как конкретно создаются формы и отчеты – это совсем другая история и относится она не к PostgreSQL, а к OpenOffice.org (см.[[ PostgreSQL. ЧАСТЬ 1: Введение|LXF85 ЧАСТЬ 1]]).

При выборе таблиц легко видеть, что они в PostgreSQL разбиты на группы. Пользовательские таблицы по умолчанию находятся в группе public. В группах pg_catalog и informaion_schema представлена системная информация и статистика.

==Что выбрать?==
Естественно, мы рассмотрели далеко не все возможные программы общего назначения для работы с PostgreSQL, но даже из того, что рассмотрено, нельзя выбрать что-то одно. Каждая программа имеет свои особенности и преимущества. psql позволяет легко работать удаленно, OpenOffice.org удовлетворяет нашу любовь к монстрам, PgAdmin III содержит множество подсказок по делу, PgAccess удивляет своей интеграцией с TCL/Tk, а TOra – «просто красивая».

Я всегда выбирал psql, но это скорее всего связано со специфичностью решаемых мной задач. Я вполне могу представить себе ситуацию, когда наличие, например, TOra значительно облегчит жизнь. Ну и не следует забывать про данные, которые кто-то должен вводить. Если лень писать специальную программу (которую лучше все-таки написать), то OpenOffice.org поможет, особенно если вводить не вам.

==См.также==
* [[Азбука SQL]]
* [[SQL]]

==Примечания==
<references />

LXF85:PostgreSQL

2008-03-12T12:08:53Z

PonElA:

<<[[LXF85]]

[[Евгений Балдин]] готов познакомить вас с замечательной СУБД [[PostgreSQL]] – а также людьми, которые ее разрабатывают.

'''PostgreSQL. ЧАСТЬ 1: Введение'''

:Разве же так можно? Разве же такие вещи алгоритмизируешь?
:Магнус Ф. Редькин об определениях счастья.
::«Понедельник начинается в субботу»

'''Н'''овая информация добывается потом и кровью. Чтобы не утерять найденное, ее надо сохранить. А чтобы потом суметь найти необходимое, ее следует структурировать. PostgreSQL предназначен для постоянного<ref>Постоянность означает сохранность данных, даже если программа перестала работать.</ref> хранения структурированных данных<ref>Хранить можно и не структурированные данные, но это уже моветон.</ref>

==Это кто такой?==
PostgreSQL – это реляционная база данных. PostgreSQL – это программный продукт с открытым исходным кодом и свободной (в прямом смысле этого слова) лицензией. Собственно говоря, этим все сказано.

==Реляционная база данных==
Информация в реляционных базах данных хранится в виде обычных плоских двумерных таблиц. Доступ к данным в таблице можно получить по ее имени. В таблице есть именованные столбцы (column) и строки (row) – очень простая и понятная концепция. Пользователю предоставляется набор операторов, результатом действий которых так же являются таблицы. Эта особенность реляционной базы данных называется замкнутость. Это очень важное свойство, так как в результате любых действий порождаются объекты того же типа, что и объект, над которым совершались эти самый действия. Следствием замкнутости является возможность применять к результату все имеющиеся в наличии операторы. Иными словами, можно пользоваться вложенными выражениями<ref>Вложенные выражения – это многоуровневые выражения, причем использование имен реальных таблиц обязательно только на самом низком уровне. В остальных случаях в качестве объектов действия могут быть вычисляемые выражения.</ref>.

ﬁodata id ﬁo
1 Иванов И.П.
2 Балдин Е.М.

SELECT ﬁodata.id=phonedata.id

phonedata id number
1 555-32-23
2 555-41-37
2 (8)555932391

ﬁo number
Иванов И.П. 555-32-23
Балдин Е.М. 555-41-37
Балдин Е.М. (8)555932391

Получение новой таблицы из уже имеющихся.

==Открытый исходный код==
PostgreSQL распространяется под лицензией BSD. Почему не GPL? Ответ разработчиков можно перевести<ref>Очень вольный перевод.</ref> примерно так: «PostgreSQL создавался в Беркли (Berkeley), как, собственно говоря, и лицензияBSD. Эта лицензия служила нам верой и правдой много лет. От добра – добра не ищут. Просьба не начинать опять «флеймить» по этому поводу.»

==Генеалогия==
Понятие реляционных баз данных было предложено в 70-ых годах прошлого века сотрудником фирмы IBM Эдгаром Ф. Коддом (Edgar F. Codd). В то время это была революция в сфере хранения данных. Головокружительный успех идей Кодда был связан еще и с тем, что он сумел воплотить математическую абстракцию под названием «реляционная алгебра» в жизнь. Многие ответы на практические вопросы были найдены теоретически с использованием математики.

С тех пор прошло более тридцати лет, и новой революции пока не предвидится. Двумерные таблицы еще долго будут основным методом структурирования информации в силу исключительной простоты решения.

Как и в случае с TCP/IP, практическое воплощение теории в жизнь началось с того, что DARPA (Defense Advanced Research Projects Agency) дало денег профессору. Профессор Майкл Стоунбрэйкер (Michael Stonebraker) написал реляционную базу данных POSTGRES, первый релиз которой был сделан в 1987 году. Профессор Стоунбрэйкер писал базу не с нуля. Его проект основывался на одной из самых первых реляционных баз данных Ingres, к созданию которой приложил руку сам Кодд – ее имя частично присутствует в названии проекта (POST-GRES – после Ingres).

POSTGRES использовался как для реальной работы в качестве СУБД, так и для исследования теории реляционных баз данных в стенах университетов. В 1994 году два студента – Андрэ Ю (Andrew Yu) и Джолли Чен (Jolly Chen) – добавили движок SQL, который уже к этому моменту стал бесспорным промышленным стандартом для реляционных СУБД. Так появился Postgres95, который в 1996 году сменил имя на PostgreSQL. Имя больше не менялось, но активная разработка не прекращается не на миг. Последней версией (по состоянию на лето 2006 года) была 8.1.4. Подробнее об истории можно узнать в стандартной документации, поставляемой с программой, или на сайте http://www.postgresql.org.

Семейство Ingres/PostgreSQL породило множество коммерческих реализаций<ref>Особенно много потомков у Ingres — та же Sybase. Код Sybase, в свою очередь, в 1992 году был продан одной известной фирме, которая чуть позже выпустила продукт, в названии которого есть имя этой фирмы и слова «SQL Server». У POSTGRES в прямых потомках ходит Informix.</ref> систем управления баз данных, благо лицензия это позволяет.

==А как оно работает?==
На рисунке показана схема работы типичного приложения. Процессу POSTMASTER, который существует всегда<ref>За исключением тех случаев, когда компьютер выключен или сервис был остановлен администратором и очень редко по причине какой-либо ошибки. Я не знаю, какая статистика у других, но из моего опыта все ошибки такого рода были связаны с человеческим фактором.</ref>, на серверную машину посылается запрос на подключение. Если запрос на подключение проходит проверку, то POSTMASTER создает свою копию. Все дальнейшие операции между базой данных и клиентом проводятся через эту копию POSTMASTER. На каждое соединение создается своя копия – это позволяет производить все действия с данными непосредственно на сервере.

Клиент Сеть Сервер Дисковая подсистема
запрос на подсоединение -> POSTMASTER
fork
Приложение <- SQL запросы -> POSTMASTER <- передача данных -> БД

Схема работы приложения с PostgreSQL.

==Установка и запуск==
Установка базы данных – это не совсем тривиальная процедура. Лучше довериться стандартной сборке из вашего базового дистрибутива, даже если версия по умолчанию кажется устаревшей. Базовая версия PostgreSQL в Debian stable (Sarge) на момент написания статьи 7.4.7, в то время как последняя версия базы данных – 8.1.4. Различия есть, и весьма существенные, но для большинства задач вам хватит и 7.x. Самостоятельно собирать пакет из исходных текстов рекомендуется лишь в том случае, когда точно известно, что в базовой версии нет необходимой функциональности.

Если в будущем необходимо будет сменить версию PostgreSQL, то следует учитывать, что в случае крупных изменений (major releases) могут меняться внутренние форматы системных таблиц и файлов данных. В этих случаях необходимо выполнить процедуру dump/restore, которая гарантированно сохранит данные при «переезде». В отличие от крупных изменений, небольшие правки (minor releases<ref>Меняется только последнее число в версии, то есть переход от версии 7.4.0 к версии 7.4.1.)</ref> не требуют никаких действий со стороны администратора БД.

Число пакетов, в описании которых упоминается PostgeSQL, довольно велико. Например, в Debian (Sarge) таких пакетов 182, что несколько меньше, чем число пакетов связанных с именем mysql (212), но превышает число упоминаний InterBase/Firebird (22), sqlite (50) и, естественно, Oracle (19). Это ни о чем не говорит, но корреляция, скорее всего, какая-то есть. К счастью, все 182 пакета ставить не обязательно – для Debian (Sarge) достаточно двух/трех:
# устанавливаются исполняемые файлы и файлы настроек
# необходимые для функционирования Базы Данных
> apt-get install postgresql
В случае подобной установки в обязательном порядке доставляется пакет PostgreSQL-client – базовый набор программ, которые можно ставить на клиентских машинах для удаленной связи с БД.

Если же, несмотря ни на что, хочется собрать все самостоятельно, то следует выполнить примерно следующую последовательность действий:
> wget ftp://ftp.postgresql.org/pub/source/v8.1.4/PostgreSQL-8.1.4.tar.bz2
> tar xvfj postgresql-8.1.4.tar.bz2
> cd postgresql-8.1.4
> ./configure
> make
> su
> make install
> adduser postgres
> mkdir /usr/local/pgsql/data
> chown postgres /usr/local/pgsql/data
> su - postgres
> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
> /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1
&
> /usr/local/pgsql/bin/createdb test
> /usr/local/pgsql/bin/psql test

Разберем то, что происходит, поподробнее. После того, как с помощью wget получен и распакован архив с исходными текстами, привычные команды ./configure и make позволяют осуществить сборку PostgreSQL. Установку (make install) следует производить под суперпользователем (su). После установки необходимо добавить пользователя postgres, от имени которого и будет запущен сервер postmaster. По умолчанию установка программы производится в директорию /usr/local/pgsql/. Для хранения файлов базы предлагается создать директорию /usr/local/pgsql/data. Данные должны принадлежать пользователю postgres (команда chown). В этой же директории хранятся и файлы настройки.

Дальнейшая настройка производится под пользователем postgres (su – postgres). С помощью команды initdb производится инициализация хранилища данных, а вслед за этим производится запуск сервера postmaster. Последние две строчки создают тестовую базу данных test (createdb) и проверяют, что к ней можно подсоединиться (psql). Если все прошло нормально, то должно появиться приглашение вида:
Welcome to psql 8.1.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

test=#
При установке стандартными средствами дистрибутива описанные выше действия выполняются автоматически, кроме последних двух строчек. В случае Debian (Sarge) при установке PostgreSQL можно указать, где именно расположить директорию с данными. По умолчанию все помещается в /var/lib/postgres/data. Для других дистрибутивов возможны вариации. Для выяснения подробностей следует изучить README. Например, в случае Debian, особенности пакета, связанные с README. Например, в случае Debian, особенности пакета, связанные с дистрибутивом, описаны в /usr/share/doc/postgresql/README.Debian.gz Ниже, если не указано специально, все действия выполняются для дистрибутива Debian (Sarge).

Для администрирования базы данных нет необходимости становиться root. Для этого можно настроить sudo (man sudo), то есть в файл /etc/sudoers (man sudoers) следует добавить примерно следующие строки:
# /etc/sudoers
Host_Alias HOME = localhost
User_Alias DBADM = “ваше имя, если Вы администратор базы данных”
Cmnd_Alias DB = /etc/init.d/postgresql
DBADM HOME = NOPASSWD: DB
DBADM HOME = (postgres) NOPASSWD: ALL
Файлы настройки принадлежат пользователю postgres, поэтому для их изменения необходимо иметь возможность заходить под этим пользователем:
> sudo -u postgres bash
> whoami
postgres
либо добавить себя в группу postgres и разрешить этой группе редактировать конфигурационные файлы в директории /etc/postgres(chgrp + chmod g+w).
{{Врезка|right|Ширина=200px
|Заголовок=К вопросу о номере порта
|Содержание=По умолчанию для создания TCP/IP соединения postmaster использует порт номер 5432. Если номер порта отличается от установленного по умолчанию, то postmaster должен быть запущен с ключом -p [номер порта].

Для выяснения этого достаточно выполнить:
<pre><nowiki>
> ps axw | grep
postmaster | grep -v grep
4181 ? S 0:00 /
usr/lib/postgresql/bin/
postmaster -D /home/
postgres/data
</nowiki></pre>
Номер порта может также храниться в переменной окружения $PGPORT..}}

Скрипт /etc/init.d/postgresql позволяет управлять процессом postmaster
> sudo /etc/init.d/postgresql
Usage: /etc/init.d/postgresql {start|stop|autovac-start|autovac-
stop|restart|autovac-restart|reload|force-reload|status}
> sudo /etc/init.d/postgresql status
pg_ctl: postmaster is running (PID: 10868)
Command line was:
/usr/lib/postgresql/bin/postmaster ‘-D’ ‘/home/postgres/data’
Этот же скрипт используется для автоматического запуска сервера при загрузке компьютера. От дистрибутива к дистрибутиву название инициализирующего скрипта может меняться.

После настройки сервера необходимо создать базу данных:
> sudo -u postgres createdb “имя БД”
CREATE DATABASE
и завести пользователя:
> sudo -u postgres createuser “имя пользователя”
Разрешить новому пользователю создавать базы? (y/n) n
Разрешить новому пользователю создавать пользователей? (y/n) n
CREATE USER
Для того чтобы пройти проверку при запросе на подключения необходимо, чтобы конфигурационный файл pg_hba.conf был настроен соответствующим образом. Например, чтобы можно было подключаться к базе данных под тем же именем, под которым вы работаете в системе, в pg_hba.conf должны присутствовать примерно следующие строки:
#/etc/PostgreSQL/pg_hba.conf
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
# connections by UNIX sockets
local all all ident sameuser
# All IPv4 connections from localhost
host all all 127.0.0.1 255.255.255.255 ident sameuser
Здесь в качестве метода идентификации используется метод ident sameuser<ref>Существует более либеральный метод проверки trust — в этом случае пускается кто угодно и под каким угодно пользователем. То есть метод «двери настежь» — некоторым нравится.</ref>. Создав пользователя в соответствии с текущей учетной записью, можно подсоединиться к PostgreSQL и начать общаться с сервером базы данных на его родном языке – SQL:
> psql “имя БД”

“имя БД”=> SELECT fio,number FROM fiodata, phonedata
“имя БД”=> WHERE fiodata.id=phonedata.id;

==Почему?==
Люди обычно работают с текстовыми файлами. Подавляющий объем структурированной информации до сих пор доставляется до нашего сознания через тест. Без помощи компьютера, в процессе ручного набора текста, информации производится не так уж и много. Необходимость базы данных в начале пути накопления личной информации не является очевидной. Все сделанное, в принципе, возможно окинуть взглядом.

==Почему БД?==
То, что создал один человек, другой человек, с высокой степенью вероятности, освоить в состоянии, но разобраться с наследием двух и более людей становится трудновато. А если это не наследие, а информация, идущая в реальном времени из многих (десятков, сотен, тысяч, миллионов) источников? Для начала все это надо куда-то сохранить, то есть необходимо надежное хранилище, по возможности ни от чего не зависящее.

И это еще полдела: данные надо как-то извлечь, причем не абсолютно все (иначе человеческий мозг в них утонет), а только нужные. Компьютеры пока еще не умеют надежно<ref>Удачные опыты по управлению курсором мыши или манипулятором уже зафиксированы, правда, для этого требуются имплантанты. Без имплантантов операторы могут передавать только самые простейшие команды, и вряд ли в ближайшее время ситуация кардинально изменится.</ref> считывать человеческие мысли, поэтому для начала необходимо нужные данные как-то пометить, и лучше это сделать в момент «укладки» в хранилище. То есть хранилище должно быть структурированным, причем структуру можно задавать извне до появления данных.

Когда данных немного – жить можно и так, оставляя ключевую информацию на обрывке листика, надеясь что он не затеряется. Обрывок листика слабо отличается от записи в каком-то файле. Текстовые утилиты типа grep существенно облегчают поиск информации, но всегда, в конце концов, настает момент, когда данных становится либо слишком много, либо они слишком часто изменяются и нужно вводить систему – Систему Управления Базой Данных или СУБД.

==Почему PostgreSQL?==
Когда я примерно шесть лет назад пытался понять, какую СУБД следует использовать для обеспечения эксперимента, в котором я участвую до сих пор, то выбора просто не существовало. Из свободных СУБД только PostgreSQL на тот момент обладал необходимой функциональностью. На сегодня вопрос выбора немного усложнился: подрос в хорошем смысле этого слова MySQL (в последней, 5-ой версии, говорят, наконец-то даже триггеры появились), были открыты исходные тексты проекта Firebird, в девичестве Interbase от фирмы Borland, да и «игрушечные» проекты типа SQLite тоже не лишены определенных преимуществ. Ну и, естественно, свет клином на открытых проектах не сошелся – тот же Oracle [бесплатно] предлагает свои СУБД для изучения. И все-таки я выбираю PostgreSQL – решение шестилетней давности меня не разочаровало. На редкость устойчивая к внешним воздействиям программа с абсолютно предсказуемым поведением. Даже те случаи, которые мне по неопытности показались «граблями», оказались «фичами».

Одной из основных целей, которая была поставлена при разработке PostgreSQL, является строгое соответствие стандартам. PostgreSQL поддерживает ANSI SQL–92, SQL–99 (SQL–2 и SQL–3, соответственно), а также многие из возможностей ANSI SQL:2003. Мало кому<ref>Возможно, что вообще никому. В большинстве случаев, следование стандарту заканчивается на вводном (entry) уровне SQL-92.</ref> удается похвастаться подобным соответствием стандартам.

В дополнение к стандартам, PostgreSQL поддерживает множество полезных расширений. Примером мелкого, но полезного расширения, не входящего в стандарт SQL, являются дополнения к условию для SELECT вида LIMIT/OFFSET<ref>Мне эти инструкции в свое время сильно облегчили жизнь, точнее, увеличили скорость выполнения нужных мне запросов</ref>, которые позволяют получить только указанные строки из результата запроса. PostgreSQL полностью поддерживает механизм транзакций (transactions), вложенные запросы (subselects), триггеры (triggers), представления (views), функциональные индексы, ссылочную целостность по внешнему ключу (foreign key referential integrity), изощренные типы блокировок (sophisticated locking) и многое другое.

К названию PostgreSQL обычно прибавляется слово «объектная», то есть полное наименование звучит как «объектно-реляционная база данных PostgreSQL». Пользователю предоставляются необходимые инструменты для создания новых типов данных, функций, операторов и своих методов индексирования. Подобные возможности позволяют работать с довольно нестандартными данными, например, с картографическими объектами – PostGIS (http://postgis.refractions.net/).

Размер базы данных, управляемой PostgreSQL, не ограничен, также нет ограничения и на число строк в таблице. Да и вообще, есть ли ограничения у этого чуда? Да, есть: ваша таблица не может быть больше чем 32 Тбайта, а число столбцов в таблице не может быть больше 250–1600, в зависимости от типа данных. Много это или мало? Зависит от задачи: я, например, как-то уперся в ограничение по числу столбцов, но скорее по неопытности, нежели по необходимости. Описанное выше верно для версии PostgreSQL 8.1.4. Возможно, в будущем будут сняты и эти ограничения.

Существует родные интерфейсы для работы с PostgreSQL из языков Java (JDBC), Perl, Python, Ruby, C, C++, PHP, Lisp, Scheme и всего, что может связаться через ODBC. PostgreSQL поддерживает хранимые процедуры, которые можно написать на множестве языков программирования, включая Java, Perl, Python, Ruby, Tcl, C/C++ и родном для PostgreSQL PL/pgSQL.

По результатам автоматизированного тестирования, проведенном в 2005 году (http://www.postgresql.org/about/news.363), в коде PostgreSQL было обнаружено 20 дефектов, что соответствует 1 ошибке на 39 тысяч строк кода. Для сравнения, аналогичное тестирование примерно в то же время выявило по одному дефекту на 10 тысяч строк кода в ядре Linux, а в MySQL одно проблемное место приходится на 4 тысячи строк кода. Это ни о чем не говорит, так сказать, мелочь, зато разработчикам и пользователям PostgreSQL приятно.

==Информация о...==
Книг по PostgreSQL, выпущенных на русском языке, относительно<ref>Например, относительно числа книг по PHP+MySQL.</ref> немного, но они есть, и количество их будет расти. Эта область технических знаний не так популярна, как следовало бы. Очевидно, что в будущем без надежных хранилищ данных будет непросто управляться со все возрастающим потоком информации.

С другой стороны, наличие отличной документации (в том числе и русскоязычной) позволяет достаточно безболезненно «войти в тему». Вполне можно обойтись и без специфичных для PostgreSQL возможностей, а для изучения основ SQL годится любая нормальная книга, коих довольно много. Для введения вполне сгодится «SQL» от Мартина Грабера (издательство «Лори», 2003). Собственно говоря, хватит и стандартной документации, которая идет в дистрибутиве.

Основной сайт PostgreSQL находится по адресу: http://www.postgresql.org. Там расположено первичное хранилище обширной документации, в которой есть фактически вся «мудрость мира», имеющая хоть какое-то отношение к PostgreSQL – надо только уметь читать.

По адресу http://www.linuxshare.ru/postgresql/ представлена русскоязычная версия сайта. Там же можно найти информацию о русскоязычном тематическом списке рассылки pgsql-ru-general-owner@postgresql.org. Список не сильно активный, но если хочется перемолвиться о «subj» по-русски – вполне сгодится.

==Примечания==
<references />

LXF85:PostgreSQL

2008-03-12T12:08:37Z

PonElA:

<<[[LXF85]]
[[Евгений Балдин]] готов познакомить вас с замечательной СУБД [[PostgreSQL]] – а также людьми, которые ее разрабатывают.

'''PostgreSQL. ЧАСТЬ 1: Введение'''

:Разве же так можно? Разве же такие вещи алгоритмизируешь?
:Магнус Ф. Редькин об определениях счастья.
::«Понедельник начинается в субботу»

'''Н'''овая информация добывается потом и кровью. Чтобы не утерять найденное, ее надо сохранить. А чтобы потом суметь найти необходимое, ее следует структурировать. PostgreSQL предназначен для постоянного<ref>Постоянность означает сохранность данных, даже если программа перестала работать.</ref> хранения структурированных данных<ref>Хранить можно и не структурированные данные, но это уже моветон.</ref>

==Это кто такой?==
PostgreSQL – это реляционная база данных. PostgreSQL – это программный продукт с открытым исходным кодом и свободной (в прямом смысле этого слова) лицензией. Собственно говоря, этим все сказано.

==Реляционная база данных==
Информация в реляционных базах данных хранится в виде обычных плоских двумерных таблиц. Доступ к данным в таблице можно получить по ее имени. В таблице есть именованные столбцы (column) и строки (row) – очень простая и понятная концепция. Пользователю предоставляется набор операторов, результатом действий которых так же являются таблицы. Эта особенность реляционной базы данных называется замкнутость. Это очень важное свойство, так как в результате любых действий порождаются объекты того же типа, что и объект, над которым совершались эти самый действия. Следствием замкнутости является возможность применять к результату все имеющиеся в наличии операторы. Иными словами, можно пользоваться вложенными выражениями<ref>Вложенные выражения – это многоуровневые выражения, причем использование имен реальных таблиц обязательно только на самом низком уровне. В остальных случаях в качестве объектов действия могут быть вычисляемые выражения.</ref>.

ﬁodata id ﬁo
1 Иванов И.П.
2 Балдин Е.М.

SELECT ﬁodata.id=phonedata.id

phonedata id number
1 555-32-23
2 555-41-37
2 (8)555932391

ﬁo number
Иванов И.П. 555-32-23
Балдин Е.М. 555-41-37
Балдин Е.М. (8)555932391

Получение новой таблицы из уже имеющихся.

==Открытый исходный код==
PostgreSQL распространяется под лицензией BSD. Почему не GPL? Ответ разработчиков можно перевести<ref>Очень вольный перевод.</ref> примерно так: «PostgreSQL создавался в Беркли (Berkeley), как, собственно говоря, и лицензияBSD. Эта лицензия служила нам верой и правдой много лет. От добра – добра не ищут. Просьба не начинать опять «флеймить» по этому поводу.»

==Генеалогия==
Понятие реляционных баз данных было предложено в 70-ых годах прошлого века сотрудником фирмы IBM Эдгаром Ф. Коддом (Edgar F. Codd). В то время это была революция в сфере хранения данных. Головокружительный успех идей Кодда был связан еще и с тем, что он сумел воплотить математическую абстракцию под названием «реляционная алгебра» в жизнь. Многие ответы на практические вопросы были найдены теоретически с использованием математики.

С тех пор прошло более тридцати лет, и новой революции пока не предвидится. Двумерные таблицы еще долго будут основным методом структурирования информации в силу исключительной простоты решения.

Как и в случае с TCP/IP, практическое воплощение теории в жизнь началось с того, что DARPA (Defense Advanced Research Projects Agency) дало денег профессору. Профессор Майкл Стоунбрэйкер (Michael Stonebraker) написал реляционную базу данных POSTGRES, первый релиз которой был сделан в 1987 году. Профессор Стоунбрэйкер писал базу не с нуля. Его проект основывался на одной из самых первых реляционных баз данных Ingres, к созданию которой приложил руку сам Кодд – ее имя частично присутствует в названии проекта (POST-GRES – после Ingres).

POSTGRES использовался как для реальной работы в качестве СУБД, так и для исследования теории реляционных баз данных в стенах университетов. В 1994 году два студента – Андрэ Ю (Andrew Yu) и Джолли Чен (Jolly Chen) – добавили движок SQL, который уже к этому моменту стал бесспорным промышленным стандартом для реляционных СУБД. Так появился Postgres95, который в 1996 году сменил имя на PostgreSQL. Имя больше не менялось, но активная разработка не прекращается не на миг. Последней версией (по состоянию на лето 2006 года) была 8.1.4. Подробнее об истории можно узнать в стандартной документации, поставляемой с программой, или на сайте http://www.postgresql.org.

Семейство Ingres/PostgreSQL породило множество коммерческих реализаций<ref>Особенно много потомков у Ingres — та же Sybase. Код Sybase, в свою очередь, в 1992 году был продан одной известной фирме, которая чуть позже выпустила продукт, в названии которого есть имя этой фирмы и слова «SQL Server». У POSTGRES в прямых потомках ходит Informix.</ref> систем управления баз данных, благо лицензия это позволяет.

==А как оно работает?==
На рисунке показана схема работы типичного приложения. Процессу POSTMASTER, который существует всегда<ref>За исключением тех случаев, когда компьютер выключен или сервис был остановлен администратором и очень редко по причине какой-либо ошибки. Я не знаю, какая статистика у других, но из моего опыта все ошибки такого рода были связаны с человеческим фактором.</ref>, на серверную машину посылается запрос на подключение. Если запрос на подключение проходит проверку, то POSTMASTER создает свою копию. Все дальнейшие операции между базой данных и клиентом проводятся через эту копию POSTMASTER. На каждое соединение создается своя копия – это позволяет производить все действия с данными непосредственно на сервере.

Клиент Сеть Сервер Дисковая подсистема
запрос на подсоединение -> POSTMASTER
fork
Приложение <- SQL запросы -> POSTMASTER <- передача данных -> БД

Схема работы приложения с PostgreSQL.

==Установка и запуск==
Установка базы данных – это не совсем тривиальная процедура. Лучше довериться стандартной сборке из вашего базового дистрибутива, даже если версия по умолчанию кажется устаревшей. Базовая версия PostgreSQL в Debian stable (Sarge) на момент написания статьи 7.4.7, в то время как последняя версия базы данных – 8.1.4. Различия есть, и весьма существенные, но для большинства задач вам хватит и 7.x. Самостоятельно собирать пакет из исходных текстов рекомендуется лишь в том случае, когда точно известно, что в базовой версии нет необходимой функциональности.

Если в будущем необходимо будет сменить версию PostgreSQL, то следует учитывать, что в случае крупных изменений (major releases) могут меняться внутренние форматы системных таблиц и файлов данных. В этих случаях необходимо выполнить процедуру dump/restore, которая гарантированно сохранит данные при «переезде». В отличие от крупных изменений, небольшие правки (minor releases<ref>Меняется только последнее число в версии, то есть переход от версии 7.4.0 к версии 7.4.1.)</ref> не требуют никаких действий со стороны администратора БД.

Число пакетов, в описании которых упоминается PostgeSQL, довольно велико. Например, в Debian (Sarge) таких пакетов 182, что несколько меньше, чем число пакетов связанных с именем mysql (212), но превышает число упоминаний InterBase/Firebird (22), sqlite (50) и, естественно, Oracle (19). Это ни о чем не говорит, но корреляция, скорее всего, какая-то есть. К счастью, все 182 пакета ставить не обязательно – для Debian (Sarge) достаточно двух/трех:
# устанавливаются исполняемые файлы и файлы настроек
# необходимые для функционирования Базы Данных
> apt-get install postgresql
В случае подобной установки в обязательном порядке доставляется пакет PostgreSQL-client – базовый набор программ, которые можно ставить на клиентских машинах для удаленной связи с БД.

Если же, несмотря ни на что, хочется собрать все самостоятельно, то следует выполнить примерно следующую последовательность действий:
> wget ftp://ftp.postgresql.org/pub/source/v8.1.4/PostgreSQL-8.1.4.tar.bz2
> tar xvfj postgresql-8.1.4.tar.bz2
> cd postgresql-8.1.4
> ./configure
> make
> su
> make install
> adduser postgres
> mkdir /usr/local/pgsql/data
> chown postgres /usr/local/pgsql/data
> su - postgres
> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
> /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1
&
> /usr/local/pgsql/bin/createdb test
> /usr/local/pgsql/bin/psql test

Разберем то, что происходит, поподробнее. После того, как с помощью wget получен и распакован архив с исходными текстами, привычные команды ./configure и make позволяют осуществить сборку PostgreSQL. Установку (make install) следует производить под суперпользователем (su). После установки необходимо добавить пользователя postgres, от имени которого и будет запущен сервер postmaster. По умолчанию установка программы производится в директорию /usr/local/pgsql/. Для хранения файлов базы предлагается создать директорию /usr/local/pgsql/data. Данные должны принадлежать пользователю postgres (команда chown). В этой же директории хранятся и файлы настройки.

Дальнейшая настройка производится под пользователем postgres (su – postgres). С помощью команды initdb производится инициализация хранилища данных, а вслед за этим производится запуск сервера postmaster. Последние две строчки создают тестовую базу данных test (createdb) и проверяют, что к ней можно подсоединиться (psql). Если все прошло нормально, то должно появиться приглашение вида:
Welcome to psql 8.1.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

test=#
При установке стандартными средствами дистрибутива описанные выше действия выполняются автоматически, кроме последних двух строчек. В случае Debian (Sarge) при установке PostgreSQL можно указать, где именно расположить директорию с данными. По умолчанию все помещается в /var/lib/postgres/data. Для других дистрибутивов возможны вариации. Для выяснения подробностей следует изучить README. Например, в случае Debian, особенности пакета, связанные с README. Например, в случае Debian, особенности пакета, связанные с дистрибутивом, описаны в /usr/share/doc/postgresql/README.Debian.gz Ниже, если не указано специально, все действия выполняются для дистрибутива Debian (Sarge).

Для администрирования базы данных нет необходимости становиться root. Для этого можно настроить sudo (man sudo), то есть в файл /etc/sudoers (man sudoers) следует добавить примерно следующие строки:
# /etc/sudoers
Host_Alias HOME = localhost
User_Alias DBADM = “ваше имя, если Вы администратор базы данных”
Cmnd_Alias DB = /etc/init.d/postgresql
DBADM HOME = NOPASSWD: DB
DBADM HOME = (postgres) NOPASSWD: ALL
Файлы настройки принадлежат пользователю postgres, поэтому для их изменения необходимо иметь возможность заходить под этим пользователем:
> sudo -u postgres bash
> whoami
postgres
либо добавить себя в группу postgres и разрешить этой группе редактировать конфигурационные файлы в директории /etc/postgres(chgrp + chmod g+w).
{{Врезка|right|Ширина=200px
|Заголовок=К вопросу о номере порта
|Содержание=По умолчанию для создания TCP/IP соединения postmaster использует порт номер 5432. Если номер порта отличается от установленного по умолчанию, то postmaster должен быть запущен с ключом -p [номер порта].

Для выяснения этого достаточно выполнить:
<pre><nowiki>
> ps axw | grep
postmaster | grep -v grep
4181 ? S 0:00 /
usr/lib/postgresql/bin/
postmaster -D /home/
postgres/data
</nowiki></pre>
Номер порта может также храниться в переменной окружения $PGPORT..}}

Скрипт /etc/init.d/postgresql позволяет управлять процессом postmaster
> sudo /etc/init.d/postgresql
Usage: /etc/init.d/postgresql {start|stop|autovac-start|autovac-
stop|restart|autovac-restart|reload|force-reload|status}
> sudo /etc/init.d/postgresql status
pg_ctl: postmaster is running (PID: 10868)
Command line was:
/usr/lib/postgresql/bin/postmaster ‘-D’ ‘/home/postgres/data’
Этот же скрипт используется для автоматического запуска сервера при загрузке компьютера. От дистрибутива к дистрибутиву название инициализирующего скрипта может меняться.

После настройки сервера необходимо создать базу данных:
> sudo -u postgres createdb “имя БД”
CREATE DATABASE
и завести пользователя:
> sudo -u postgres createuser “имя пользователя”
Разрешить новому пользователю создавать базы? (y/n) n
Разрешить новому пользователю создавать пользователей? (y/n) n
CREATE USER
Для того чтобы пройти проверку при запросе на подключения необходимо, чтобы конфигурационный файл pg_hba.conf был настроен соответствующим образом. Например, чтобы можно было подключаться к базе данных под тем же именем, под которым вы работаете в системе, в pg_hba.conf должны присутствовать примерно следующие строки:
#/etc/PostgreSQL/pg_hba.conf
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
# connections by UNIX sockets
local all all ident sameuser
# All IPv4 connections from localhost
host all all 127.0.0.1 255.255.255.255 ident sameuser
Здесь в качестве метода идентификации используется метод ident sameuser<ref>Существует более либеральный метод проверки trust — в этом случае пускается кто угодно и под каким угодно пользователем. То есть метод «двери настежь» — некоторым нравится.</ref>. Создав пользователя в соответствии с текущей учетной записью, можно подсоединиться к PostgreSQL и начать общаться с сервером базы данных на его родном языке – SQL:
> psql “имя БД”

“имя БД”=> SELECT fio,number FROM fiodata, phonedata
“имя БД”=> WHERE fiodata.id=phonedata.id;

==Почему?==
Люди обычно работают с текстовыми файлами. Подавляющий объем структурированной информации до сих пор доставляется до нашего сознания через тест. Без помощи компьютера, в процессе ручного набора текста, информации производится не так уж и много. Необходимость базы данных в начале пути накопления личной информации не является очевидной. Все сделанное, в принципе, возможно окинуть взглядом.

==Почему БД?==
То, что создал один человек, другой человек, с высокой степенью вероятности, освоить в состоянии, но разобраться с наследием двух и более людей становится трудновато. А если это не наследие, а информация, идущая в реальном времени из многих (десятков, сотен, тысяч, миллионов) источников? Для начала все это надо куда-то сохранить, то есть необходимо надежное хранилище, по возможности ни от чего не зависящее.

И это еще полдела: данные надо как-то извлечь, причем не абсолютно все (иначе человеческий мозг в них утонет), а только нужные. Компьютеры пока еще не умеют надежно<ref>Удачные опыты по управлению курсором мыши или манипулятором уже зафиксированы, правда, для этого требуются имплантанты. Без имплантантов операторы могут передавать только самые простейшие команды, и вряд ли в ближайшее время ситуация кардинально изменится.</ref> считывать человеческие мысли, поэтому для начала необходимо нужные данные как-то пометить, и лучше это сделать в момент «укладки» в хранилище. То есть хранилище должно быть структурированным, причем структуру можно задавать извне до появления данных.

Когда данных немного – жить можно и так, оставляя ключевую информацию на обрывке листика, надеясь что он не затеряется. Обрывок листика слабо отличается от записи в каком-то файле. Текстовые утилиты типа grep существенно облегчают поиск информации, но всегда, в конце концов, настает момент, когда данных становится либо слишком много, либо они слишком часто изменяются и нужно вводить систему – Систему Управления Базой Данных или СУБД.

==Почему PostgreSQL?==
Когда я примерно шесть лет назад пытался понять, какую СУБД следует использовать для обеспечения эксперимента, в котором я участвую до сих пор, то выбора просто не существовало. Из свободных СУБД только PostgreSQL на тот момент обладал необходимой функциональностью. На сегодня вопрос выбора немного усложнился: подрос в хорошем смысле этого слова MySQL (в последней, 5-ой версии, говорят, наконец-то даже триггеры появились), были открыты исходные тексты проекта Firebird, в девичестве Interbase от фирмы Borland, да и «игрушечные» проекты типа SQLite тоже не лишены определенных преимуществ. Ну и, естественно, свет клином на открытых проектах не сошелся – тот же Oracle [бесплатно] предлагает свои СУБД для изучения. И все-таки я выбираю PostgreSQL – решение шестилетней давности меня не разочаровало. На редкость устойчивая к внешним воздействиям программа с абсолютно предсказуемым поведением. Даже те случаи, которые мне по неопытности показались «граблями», оказались «фичами».

Одной из основных целей, которая была поставлена при разработке PostgreSQL, является строгое соответствие стандартам. PostgreSQL поддерживает ANSI SQL–92, SQL–99 (SQL–2 и SQL–3, соответственно), а также многие из возможностей ANSI SQL:2003. Мало кому<ref>Возможно, что вообще никому. В большинстве случаев, следование стандарту заканчивается на вводном (entry) уровне SQL-92.</ref> удается похвастаться подобным соответствием стандартам.

В дополнение к стандартам, PostgreSQL поддерживает множество полезных расширений. Примером мелкого, но полезного расширения, не входящего в стандарт SQL, являются дополнения к условию для SELECT вида LIMIT/OFFSET<ref>Мне эти инструкции в свое время сильно облегчили жизнь, точнее, увеличили скорость выполнения нужных мне запросов</ref>, которые позволяют получить только указанные строки из результата запроса. PostgreSQL полностью поддерживает механизм транзакций (transactions), вложенные запросы (subselects), триггеры (triggers), представления (views), функциональные индексы, ссылочную целостность по внешнему ключу (foreign key referential integrity), изощренные типы блокировок (sophisticated locking) и многое другое.

К названию PostgreSQL обычно прибавляется слово «объектная», то есть полное наименование звучит как «объектно-реляционная база данных PostgreSQL». Пользователю предоставляются необходимые инструменты для создания новых типов данных, функций, операторов и своих методов индексирования. Подобные возможности позволяют работать с довольно нестандартными данными, например, с картографическими объектами – PostGIS (http://postgis.refractions.net/).

Размер базы данных, управляемой PostgreSQL, не ограничен, также нет ограничения и на число строк в таблице. Да и вообще, есть ли ограничения у этого чуда? Да, есть: ваша таблица не может быть больше чем 32 Тбайта, а число столбцов в таблице не может быть больше 250–1600, в зависимости от типа данных. Много это или мало? Зависит от задачи: я, например, как-то уперся в ограничение по числу столбцов, но скорее по неопытности, нежели по необходимости. Описанное выше верно для версии PostgreSQL 8.1.4. Возможно, в будущем будут сняты и эти ограничения.

Существует родные интерфейсы для работы с PostgreSQL из языков Java (JDBC), Perl, Python, Ruby, C, C++, PHP, Lisp, Scheme и всего, что может связаться через ODBC. PostgreSQL поддерживает хранимые процедуры, которые можно написать на множестве языков программирования, включая Java, Perl, Python, Ruby, Tcl, C/C++ и родном для PostgreSQL PL/pgSQL.

По результатам автоматизированного тестирования, проведенном в 2005 году (http://www.postgresql.org/about/news.363), в коде PostgreSQL было обнаружено 20 дефектов, что соответствует 1 ошибке на 39 тысяч строк кода. Для сравнения, аналогичное тестирование примерно в то же время выявило по одному дефекту на 10 тысяч строк кода в ядре Linux, а в MySQL одно проблемное место приходится на 4 тысячи строк кода. Это ни о чем не говорит, так сказать, мелочь, зато разработчикам и пользователям PostgreSQL приятно.

==Информация о...==
Книг по PostgreSQL, выпущенных на русском языке, относительно<ref>Например, относительно числа книг по PHP+MySQL.</ref> немного, но они есть, и количество их будет расти. Эта область технических знаний не так популярна, как следовало бы. Очевидно, что в будущем без надежных хранилищ данных будет непросто управляться со все возрастающим потоком информации.

С другой стороны, наличие отличной документации (в том числе и русскоязычной) позволяет достаточно безболезненно «войти в тему». Вполне можно обойтись и без специфичных для PostgreSQL возможностей, а для изучения основ SQL годится любая нормальная книга, коих довольно много. Для введения вполне сгодится «SQL» от Мартина Грабера (издательство «Лори», 2003). Собственно говоря, хватит и стандартной документации, которая идет в дистрибутиве.

Основной сайт PostgreSQL находится по адресу: http://www.postgresql.org. Там расположено первичное хранилище обширной документации, в которой есть фактически вся «мудрость мира», имеющая хоть какое-то отношение к PostgreSQL – надо только уметь читать.

По адресу http://www.linuxshare.ru/postgresql/ представлена русскоязычная версия сайта. Там же можно найти информацию о русскоязычном тематическом списке рассылки pgsql-ru-general-owner@postgresql.org. Список не сильно активный, но если хочется перемолвиться о «subj» по-русски – вполне сгодится.

==Примечания==
<references />

LXF85:PostgreSQL

2008-03-12T12:06:25Z

PonElA:

[[Евгений Балдин]] готов познакомить вас с замечательной СУБД [[PostgreSQL]] – а также людьми, которые ее разрабатывают.

'''PostgreSQL. ЧАСТЬ 1: Введение'''

:Разве же так можно? Разве же такие вещи алгоритмизируешь?
:Магнус Ф. Редькин об определениях счастья.
::«Понедельник начинается в субботу»

'''Н'''овая информация добывается потом и кровью. Чтобы не утерять найденное, ее надо сохранить. А чтобы потом суметь найти необходимое, ее следует структурировать. PostgreSQL предназначен для постоянного<ref>Постоянность означает сохранность данных, даже если программа перестала работать.</ref> хранения структурированных данных<ref>Хранить можно и не структурированные данные, но это уже моветон.</ref>

==Это кто такой?==
PostgreSQL – это реляционная база данных. PostgreSQL – это программный продукт с открытым исходным кодом и свободной (в прямом смысле этого слова) лицензией. Собственно говоря, этим все сказано.

==Реляционная база данных==
Информация в реляционных базах данных хранится в виде обычных плоских двумерных таблиц. Доступ к данным в таблице можно получить по ее имени. В таблице есть именованные столбцы (column) и строки (row) – очень простая и понятная концепция. Пользователю предоставляется набор операторов, результатом действий которых так же являются таблицы. Эта особенность реляционной базы данных называется замкнутость. Это очень важное свойство, так как в результате любых действий порождаются объекты того же типа, что и объект, над которым совершались эти самый действия. Следствием замкнутости является возможность применять к результату все имеющиеся в наличии операторы. Иными словами, можно пользоваться вложенными выражениями<ref>Вложенные выражения – это многоуровневые выражения, причем использование имен реальных таблиц обязательно только на самом низком уровне. В остальных случаях в качестве объектов действия могут быть вычисляемые выражения.</ref>.

ﬁodata id ﬁo
1 Иванов И.П.
2 Балдин Е.М.

SELECT ﬁodata.id=phonedata.id

phonedata id number
1 555-32-23
2 555-41-37
2 (8)555932391

ﬁo number
Иванов И.П. 555-32-23
Балдин Е.М. 555-41-37
Балдин Е.М. (8)555932391

Получение новой таблицы из уже имеющихся.

==Открытый исходный код==
PostgreSQL распространяется под лицензией BSD. Почему не GPL? Ответ разработчиков можно перевести<ref>Очень вольный перевод.</ref> примерно так: «PostgreSQL создавался в Беркли (Berkeley), как, собственно говоря, и лицензияBSD. Эта лицензия служила нам верой и правдой много лет. От добра – добра не ищут. Просьба не начинать опять «флеймить» по этому поводу.»

==Генеалогия==
Понятие реляционных баз данных было предложено в 70-ых годах прошлого века сотрудником фирмы IBM Эдгаром Ф. Коддом (Edgar F. Codd). В то время это была революция в сфере хранения данных. Головокружительный успех идей Кодда был связан еще и с тем, что он сумел воплотить математическую абстракцию под названием «реляционная алгебра» в жизнь. Многие ответы на практические вопросы были найдены теоретически с использованием математики.

С тех пор прошло более тридцати лет, и новой революции пока не предвидится. Двумерные таблицы еще долго будут основным методом структурирования информации в силу исключительной простоты решения.

Как и в случае с TCP/IP, практическое воплощение теории в жизнь началось с того, что DARPA (Defense Advanced Research Projects Agency) дало денег профессору. Профессор Майкл Стоунбрэйкер (Michael Stonebraker) написал реляционную базу данных POSTGRES, первый релиз которой был сделан в 1987 году. Профессор Стоунбрэйкер писал базу не с нуля. Его проект основывался на одной из самых первых реляционных баз данных Ingres, к созданию которой приложил руку сам Кодд – ее имя частично присутствует в названии проекта (POST-GRES – после Ingres).

POSTGRES использовался как для реальной работы в качестве СУБД, так и для исследования теории реляционных баз данных в стенах университетов. В 1994 году два студента – Андрэ Ю (Andrew Yu) и Джолли Чен (Jolly Chen) – добавили движок SQL, который уже к этому моменту стал бесспорным промышленным стандартом для реляционных СУБД. Так появился Postgres95, который в 1996 году сменил имя на PostgreSQL. Имя больше не менялось, но активная разработка не прекращается не на миг. Последней версией (по состоянию на лето 2006 года) была 8.1.4. Подробнее об истории можно узнать в стандартной документации, поставляемой с программой, или на сайте http://www.postgresql.org.

Семейство Ingres/PostgreSQL породило множество коммерческих реализаций<ref>Особенно много потомков у Ingres — та же Sybase. Код Sybase, в свою очередь, в 1992 году был продан одной известной фирме, которая чуть позже выпустила продукт, в названии которого есть имя этой фирмы и слова «SQL Server». У POSTGRES в прямых потомках ходит Informix.</ref> систем управления баз данных, благо лицензия это позволяет.

==А как оно работает?==
На рисунке показана схема работы типичного приложения. Процессу POSTMASTER, который существует всегда<ref>За исключением тех случаев, когда компьютер выключен или сервис был остановлен администратором и очень редко по причине какой-либо ошибки. Я не знаю, какая статистика у других, но из моего опыта все ошибки такого рода были связаны с человеческим фактором.</ref>, на серверную машину посылается запрос на подключение. Если запрос на подключение проходит проверку, то POSTMASTER создает свою копию. Все дальнейшие операции между базой данных и клиентом проводятся через эту копию POSTMASTER. На каждое соединение создается своя копия – это позволяет производить все действия с данными непосредственно на сервере.

Клиент Сеть Сервер Дисковая подсистема
запрос на подсоединение -> POSTMASTER
fork
Приложение <- SQL запросы -> POSTMASTER <- передача данных -> БД

Схема работы приложения с PostgreSQL.

==Установка и запуск==
Установка базы данных – это не совсем тривиальная процедура. Лучше довериться стандартной сборке из вашего базового дистрибутива, даже если версия по умолчанию кажется устаревшей. Базовая версия PostgreSQL в Debian stable (Sarge) на момент написания статьи 7.4.7, в то время как последняя версия базы данных – 8.1.4. Различия есть, и весьма существенные, но для большинства задач вам хватит и 7.x. Самостоятельно собирать пакет из исходных текстов рекомендуется лишь в том случае, когда точно известно, что в базовой версии нет необходимой функциональности.

Если в будущем необходимо будет сменить версию PostgreSQL, то следует учитывать, что в случае крупных изменений (major releases) могут меняться внутренние форматы системных таблиц и файлов данных. В этих случаях необходимо выполнить процедуру dump/restore, которая гарантированно сохранит данные при «переезде». В отличие от крупных изменений, небольшие правки (minor releases<ref>Меняется только последнее число в версии, то есть переход от версии 7.4.0 к версии 7.4.1.)</ref> не требуют никаких действий со стороны администратора БД.

Число пакетов, в описании которых упоминается PostgeSQL, довольно велико. Например, в Debian (Sarge) таких пакетов 182, что несколько меньше, чем число пакетов связанных с именем mysql (212), но превышает число упоминаний InterBase/Firebird (22), sqlite (50) и, естественно, Oracle (19). Это ни о чем не говорит, но корреляция, скорее всего, какая-то есть. К счастью, все 182 пакета ставить не обязательно – для Debian (Sarge) достаточно двух/трех:
# устанавливаются исполняемые файлы и файлы настроек
# необходимые для функционирования Базы Данных
> apt-get install postgresql
В случае подобной установки в обязательном порядке доставляется пакет PostgreSQL-client – базовый набор программ, которые можно ставить на клиентских машинах для удаленной связи с БД.

Если же, несмотря ни на что, хочется собрать все самостоятельно, то следует выполнить примерно следующую последовательность действий:
> wget ftp://ftp.postgresql.org/pub/source/v8.1.4/PostgreSQL-8.1.4.tar.bz2
> tar xvfj postgresql-8.1.4.tar.bz2
> cd postgresql-8.1.4
> ./configure
> make
> su
> make install
> adduser postgres
> mkdir /usr/local/pgsql/data
> chown postgres /usr/local/pgsql/data
> su - postgres
> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
> /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1
&
> /usr/local/pgsql/bin/createdb test
> /usr/local/pgsql/bin/psql test

Разберем то, что происходит, поподробнее. После того, как с помощью wget получен и распакован архив с исходными текстами, привычные команды ./configure и make позволяют осуществить сборку PostgreSQL. Установку (make install) следует производить под суперпользователем (su). После установки необходимо добавить пользователя postgres, от имени которого и будет запущен сервер postmaster. По умолчанию установка программы производится в директорию /usr/local/pgsql/. Для хранения файлов базы предлагается создать директорию /usr/local/pgsql/data. Данные должны принадлежать пользователю postgres (команда chown). В этой же директории хранятся и файлы настройки.

Дальнейшая настройка производится под пользователем postgres (su – postgres). С помощью команды initdb производится инициализация хранилища данных, а вслед за этим производится запуск сервера postmaster. Последние две строчки создают тестовую базу данных test (createdb) и проверяют, что к ней можно подсоединиться (psql). Если все прошло нормально, то должно появиться приглашение вида:
Welcome to psql 8.1.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

test=#
При установке стандартными средствами дистрибутива описанные выше действия выполняются автоматически, кроме последних двух строчек. В случае Debian (Sarge) при установке PostgreSQL можно указать, где именно расположить директорию с данными. По умолчанию все помещается в /var/lib/postgres/data. Для других дистрибутивов возможны вариации. Для выяснения подробностей следует изучить README. Например, в случае Debian, особенности пакета, связанные с README. Например, в случае Debian, особенности пакета, связанные с дистрибутивом, описаны в /usr/share/doc/postgresql/README.Debian.gz Ниже, если не указано специально, все действия выполняются для дистрибутива Debian (Sarge).

Для администрирования базы данных нет необходимости становиться root. Для этого можно настроить sudo (man sudo), то есть в файл /etc/sudoers (man sudoers) следует добавить примерно следующие строки:
# /etc/sudoers
Host_Alias HOME = localhost
User_Alias DBADM = “ваше имя, если Вы администратор базы данных”
Cmnd_Alias DB = /etc/init.d/postgresql
DBADM HOME = NOPASSWD: DB
DBADM HOME = (postgres) NOPASSWD: ALL
Файлы настройки принадлежат пользователю postgres, поэтому для их изменения необходимо иметь возможность заходить под этим пользователем:
> sudo -u postgres bash
> whoami
postgres
либо добавить себя в группу postgres и разрешить этой группе редактировать конфигурационные файлы в директории /etc/postgres(chgrp + chmod g+w).
{{Врезка|right|Ширина=200px
|Заголовок=К вопросу о номере порта
|Содержание=По умолчанию для создания TCP/IP соединения postmaster использует порт номер 5432. Если номер порта отличается от установленного по умолчанию, то postmaster должен быть запущен с ключом -p [номер порта].

Для выяснения этого достаточно выполнить:
<pre><nowiki>
> ps axw | grep
postmaster | grep -v grep
4181 ? S 0:00 /
usr/lib/postgresql/bin/
postmaster -D /home/
postgres/data
</nowiki></pre>
Номер порта может также храниться в переменной окружения $PGPORT..}}

Скрипт /etc/init.d/postgresql позволяет управлять процессом postmaster
> sudo /etc/init.d/postgresql
Usage: /etc/init.d/postgresql {start|stop|autovac-start|autovac-
stop|restart|autovac-restart|reload|force-reload|status}
> sudo /etc/init.d/postgresql status
pg_ctl: postmaster is running (PID: 10868)
Command line was:
/usr/lib/postgresql/bin/postmaster ‘-D’ ‘/home/postgres/data’
Этот же скрипт используется для автоматического запуска сервера при загрузке компьютера. От дистрибутива к дистрибутиву название инициализирующего скрипта может меняться.

После настройки сервера необходимо создать базу данных:
> sudo -u postgres createdb “имя БД”
CREATE DATABASE
и завести пользователя:
> sudo -u postgres createuser “имя пользователя”
Разрешить новому пользователю создавать базы? (y/n) n
Разрешить новому пользователю создавать пользователей? (y/n) n
CREATE USER
Для того чтобы пройти проверку при запросе на подключения необходимо, чтобы конфигурационный файл pg_hba.conf был настроен соответствующим образом. Например, чтобы можно было подключаться к базе данных под тем же именем, под которым вы работаете в системе, в pg_hba.conf должны присутствовать примерно следующие строки:
#/etc/PostgreSQL/pg_hba.conf
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
# connections by UNIX sockets
local all all ident sameuser
# All IPv4 connections from localhost
host all all 127.0.0.1 255.255.255.255 ident sameuser
Здесь в качестве метода идентификации используется метод ident sameuser<ref>Существует более либеральный метод проверки trust — в этом случае пускается кто угодно и под каким угодно пользователем. То есть метод «двери настежь» — некоторым нравится.</ref>. Создав пользователя в соответствии с текущей учетной записью, можно подсоединиться к PostgreSQL и начать общаться с сервером базы данных на его родном языке – SQL:
> psql “имя БД”

“имя БД”=> SELECT fio,number FROM fiodata, phonedata
“имя БД”=> WHERE fiodata.id=phonedata.id;

==Почему?==
Люди обычно работают с текстовыми файлами. Подавляющий объем структурированной информации до сих пор доставляется до нашего сознания через тест. Без помощи компьютера, в процессе ручного набора текста, информации производится не так уж и много. Необходимость базы данных в начале пути накопления личной информации не является очевидной. Все сделанное, в принципе, возможно окинуть взглядом.

==Почему БД?==
То, что создал один человек, другой человек, с высокой степенью вероятности, освоить в состоянии, но разобраться с наследием двух и более людей становится трудновато. А если это не наследие, а информация, идущая в реальном времени из многих (десятков, сотен, тысяч, миллионов) источников? Для начала все это надо куда-то сохранить, то есть необходимо надежное хранилище, по возможности ни от чего не зависящее.

И это еще полдела: данные надо как-то извлечь, причем не абсолютно все (иначе человеческий мозг в них утонет), а только нужные. Компьютеры пока еще не умеют надежно<ref>Удачные опыты по управлению курсором мыши или манипулятором уже зафиксированы, правда, для этого требуются имплантанты. Без имплантантов операторы могут передавать только самые простейшие команды, и вряд ли в ближайшее время ситуация кардинально изменится.</ref> считывать человеческие мысли, поэтому для начала необходимо нужные данные как-то пометить, и лучше это сделать в момент «укладки» в хранилище. То есть хранилище должно быть структурированным, причем структуру можно задавать извне до появления данных.

Когда данных немного – жить можно и так, оставляя ключевую информацию на обрывке листика, надеясь что он не затеряется. Обрывок листика слабо отличается от записи в каком-то файле. Текстовые утилиты типа grep существенно облегчают поиск информации, но всегда, в конце концов, настает момент, когда данных становится либо слишком много, либо они слишком часто изменяются и нужно вводить систему – Систему Управления Базой Данных или СУБД.

==Почему PostgreSQL?==
Когда я примерно шесть лет назад пытался понять, какую СУБД следует использовать для обеспечения эксперимента, в котором я участвую до сих пор, то выбора просто не существовало. Из свободных СУБД только PostgreSQL на тот момент обладал необходимой функциональностью. На сегодня вопрос выбора немного усложнился: подрос в хорошем смысле этого слова MySQL (в последней, 5-ой версии, говорят, наконец-то даже триггеры появились), были открыты исходные тексты проекта Firebird, в девичестве Interbase от фирмы Borland, да и «игрушечные» проекты типа SQLite тоже не лишены определенных преимуществ. Ну и, естественно, свет клином на открытых проектах не сошелся – тот же Oracle [бесплатно] предлагает свои СУБД для изучения. И все-таки я выбираю PostgreSQL – решение шестилетней давности меня не разочаровало. На редкость устойчивая к внешним воздействиям программа с абсолютно предсказуемым поведением. Даже те случаи, которые мне по неопытности показались «граблями», оказались «фичами».

Одной из основных целей, которая была поставлена при разработке PostgreSQL, является строгое соответствие стандартам. PostgreSQL поддерживает ANSI SQL–92, SQL–99 (SQL–2 и SQL–3, соответственно), а также многие из возможностей ANSI SQL:2003. Мало кому<ref>Возможно, что вообще никому. В большинстве случаев, следование стандарту заканчивается на вводном (entry) уровне SQL-92.</ref> удается похвастаться подобным соответствием стандартам.

В дополнение к стандартам, PostgreSQL поддерживает множество полезных расширений. Примером мелкого, но полезного расширения, не входящего в стандарт SQL, являются дополнения к условию для SELECT вида LIMIT/OFFSET<ref>Мне эти инструкции в свое время сильно облегчили жизнь, точнее, увеличили скорость выполнения нужных мне запросов</ref>, которые позволяют получить только указанные строки из результата запроса. PostgreSQL полностью поддерживает механизм транзакций (transactions), вложенные запросы (subselects), триггеры (triggers), представления (views), функциональные индексы, ссылочную целостность по внешнему ключу (foreign key referential integrity), изощренные типы блокировок (sophisticated locking) и многое другое.

К названию PostgreSQL обычно прибавляется слово «объектная», то есть полное наименование звучит как «объектно-реляционная база данных PostgreSQL». Пользователю предоставляются необходимые инструменты для создания новых типов данных, функций, операторов и своих методов индексирования. Подобные возможности позволяют работать с довольно нестандартными данными, например, с картографическими объектами – PostGIS (http://postgis.refractions.net/).

Размер базы данных, управляемой PostgreSQL, не ограничен, также нет ограничения и на число строк в таблице. Да и вообще, есть ли ограничения у этого чуда? Да, есть: ваша таблица не может быть больше чем 32 Тбайта, а число столбцов в таблице не может быть больше 250–1600, в зависимости от типа данных. Много это или мало? Зависит от задачи: я, например, как-то уперся в ограничение по числу столбцов, но скорее по неопытности, нежели по необходимости. Описанное выше верно для версии PostgreSQL 8.1.4. Возможно, в будущем будут сняты и эти ограничения.

Существует родные интерфейсы для работы с PostgreSQL из языков Java (JDBC), Perl, Python, Ruby, C, C++, PHP, Lisp, Scheme и всего, что может связаться через ODBC. PostgreSQL поддерживает хранимые процедуры, которые можно написать на множестве языков программирования, включая Java, Perl, Python, Ruby, Tcl, C/C++ и родном для PostgreSQL PL/pgSQL.

По результатам автоматизированного тестирования, проведенном в 2005 году (http://www.postgresql.org/about/news.363), в коде PostgreSQL было обнаружено 20 дефектов, что соответствует 1 ошибке на 39 тысяч строк кода. Для сравнения, аналогичное тестирование примерно в то же время выявило по одному дефекту на 10 тысяч строк кода в ядре Linux, а в MySQL одно проблемное место приходится на 4 тысячи строк кода. Это ни о чем не говорит, так сказать, мелочь, зато разработчикам и пользователям PostgreSQL приятно.

==Информация о...==
Книг по PostgreSQL, выпущенных на русском языке, относительно<ref>Например, относительно числа книг по PHP+MySQL.</ref> немного, но они есть, и количество их будет расти. Эта область технических знаний не так популярна, как следовало бы. Очевидно, что в будущем без надежных хранилищ данных будет непросто управляться со все возрастающим потоком информации.

С другой стороны, наличие отличной документации (в том числе и русскоязычной) позволяет достаточно безболезненно «войти в тему». Вполне можно обойтись и без специфичных для PostgreSQL возможностей, а для изучения основ SQL годится любая нормальная книга, коих довольно много. Для введения вполне сгодится «SQL» от Мартина Грабера (издательство «Лори», 2003). Собственно говоря, хватит и стандартной документации, которая идет в дистрибутиве.

Основной сайт PostgreSQL находится по адресу: http://www.postgresql.org. Там расположено первичное хранилище обширной документации, в которой есть фактически вся «мудрость мира», имеющая хоть какое-то отношение к PostgreSQL – надо только уметь читать.

По адресу http://www.linuxshare.ru/postgresql/ представлена русскоязычная версия сайта. Там же можно найти информацию о русскоязычном тематическом списке рассылки pgsql-ru-general-owner@postgresql.org. Список не сильно активный, но если хочется перемолвиться о «subj» по-русски – вполне сгодится.

==Примечания==
<references />

LXF85:PostgreSQL

2008-03-12T12:04:56Z

PonElA: Новая: {{TOCright}} Евгений Балдин готов познакомить вас с замечательной СУБД PostgreSQL – а также людьми, которые...

{{TOCright}}
[[Евгений Балдин]] готов познакомить вас с замечательной СУБД [[PostgreSQL]] – а также людьми, которые ее разрабатывают.

:Разве же так можно? Разве же такие вещи алгоритмизируешь?
:Магнус Ф. Редькин об определениях счастья.
::«Понедельник начинается в субботу»

'''Н'''овая информация добывается потом и кровью. Чтобы не утерять найденное, ее надо сохранить. А чтобы потом суметь найти необходимое, ее следует структурировать. PostgreSQL предназначен для постоянного<ref>Постоянность означает сохранность данных, даже если программа перестала работать.</ref> хранения структурированных данных<ref>Хранить можно и не структурированные данные, но это уже моветон.</ref>

==Это кто такой?==
PostgreSQL – это реляционная база данных. PostgreSQL – это программный продукт с открытым исходным кодом и свободной (в прямом смысле этого слова) лицензией. Собственно говоря, этим все сказано.

==Реляционная база данных==
Информация в реляционных базах данных хранится в виде обычных плоских двумерных таблиц. Доступ к данным в таблице можно получить по ее имени. В таблице есть именованные столбцы (column) и строки (row) – очень простая и понятная концепция. Пользователю предоставляется набор операторов, результатом действий которых так же являются таблицы. Эта особенность реляционной базы данных называется замкнутость. Это очень важное свойство, так как в результате любых действий порождаются объекты того же типа, что и объект, над которым совершались эти самый действия. Следствием замкнутости является возможность применять к результату все имеющиеся в наличии операторы. Иными словами, можно пользоваться вложенными выражениями<ref>Вложенные выражения – это многоуровневые выражения, причем использование имен реальных таблиц обязательно только на самом низком уровне. В остальных случаях в качестве объектов действия могут быть вычисляемые выражения.</ref>.

ﬁodata id ﬁo
1 Иванов И.П.
2 Балдин Е.М.

SELECT ﬁodata.id=phonedata.id

phonedata id number
1 555-32-23
2 555-41-37
2 (8)555932391

ﬁo number
Иванов И.П. 555-32-23
Балдин Е.М. 555-41-37
Балдин Е.М. (8)555932391

Получение новой таблицы из уже имеющихся.

==Открытый исходный код==
PostgreSQL распространяется под лицензией BSD. Почему не GPL? Ответ разработчиков можно перевести<ref>Очень вольный перевод.</ref> примерно так: «PostgreSQL создавался в Беркли (Berkeley), как, собственно говоря, и лицензияBSD. Эта лицензия служила нам верой и правдой много лет. От добра – добра не ищут. Просьба не начинать опять «флеймить» по этому поводу.»

==Генеалогия==
Понятие реляционных баз данных было предложено в 70-ых годах прошлого века сотрудником фирмы IBM Эдгаром Ф. Коддом (Edgar F. Codd). В то время это была революция в сфере хранения данных. Головокружительный успех идей Кодда был связан еще и с тем, что он сумел воплотить математическую абстракцию под названием «реляционная алгебра» в жизнь. Многие ответы на практические вопросы были найдены теоретически с использованием математики.

С тех пор прошло более тридцати лет, и новой революции пока не предвидится. Двумерные таблицы еще долго будут основным методом структурирования информации в силу исключительной простоты решения.

Как и в случае с TCP/IP, практическое воплощение теории в жизнь началось с того, что DARPA (Defense Advanced Research Projects Agency) дало денег профессору. Профессор Майкл Стоунбрэйкер (Michael Stonebraker) написал реляционную базу данных POSTGRES, первый релиз которой был сделан в 1987 году. Профессор Стоунбрэйкер писал базу не с нуля. Его проект основывался на одной из самых первых реляционных баз данных Ingres, к созданию которой приложил руку сам Кодд – ее имя частично присутствует в названии проекта (POST-GRES – после Ingres).

POSTGRES использовался как для реальной работы в качестве СУБД, так и для исследования теории реляционных баз данных в стенах университетов. В 1994 году два студента – Андрэ Ю (Andrew Yu) и Джолли Чен (Jolly Chen) – добавили движок SQL, который уже к этому моменту стал бесспорным промышленным стандартом для реляционных СУБД. Так появился Postgres95, который в 1996 году сменил имя на PostgreSQL. Имя больше не менялось, но активная разработка не прекращается не на миг. Последней версией (по состоянию на лето 2006 года) была 8.1.4. Подробнее об истории можно узнать в стандартной документации, поставляемой с программой, или на сайте http://www.postgresql.org.

Семейство Ingres/PostgreSQL породило множество коммерческих реализаций<ref>Особенно много потомков у Ingres — та же Sybase. Код Sybase, в свою очередь, в 1992 году был продан одной известной фирме, которая чуть позже выпустила продукт, в названии которого есть имя этой фирмы и слова «SQL Server». У POSTGRES в прямых потомках ходит Informix.</ref> систем управления баз данных, благо лицензия это позволяет.

==А как оно работает?==
На рисунке показана схема работы типичного приложения. Процессу POSTMASTER, который существует всегда<ref>За исключением тех случаев, когда компьютер выключен или сервис был остановлен администратором и очень редко по причине какой-либо ошибки. Я не знаю, какая статистика у других, но из моего опыта все ошибки такого рода были связаны с человеческим фактором.</ref>, на серверную машину посылается запрос на подключение. Если запрос на подключение проходит проверку, то POSTMASTER создает свою копию. Все дальнейшие операции между базой данных и клиентом проводятся через эту копию POSTMASTER. На каждое соединение создается своя копия – это позволяет производить все действия с данными непосредственно на сервере.

Клиент Сеть Сервер Дисковая подсистема
запрос на подсоединение -> POSTMASTER
fork
Приложение <- SQL запросы -> POSTMASTER <- передача данных -> БД

Схема работы приложения с PostgreSQL.

==Установка и запуск==
Установка базы данных – это не совсем тривиальная процедура. Лучше довериться стандартной сборке из вашего базового дистрибутива, даже если версия по умолчанию кажется устаревшей. Базовая версия PostgreSQL в Debian stable (Sarge) на момент написания статьи 7.4.7, в то время как последняя версия базы данных – 8.1.4. Различия есть, и весьма существенные, но для большинства задач вам хватит и 7.x. Самостоятельно собирать пакет из исходных текстов рекомендуется лишь в том случае, когда точно известно, что в базовой версии нет необходимой функциональности.

Если в будущем необходимо будет сменить версию PostgreSQL, то следует учитывать, что в случае крупных изменений (major releases) могут меняться внутренние форматы системных таблиц и файлов данных. В этих случаях необходимо выполнить процедуру dump/restore, которая гарантированно сохранит данные при «переезде». В отличие от крупных изменений, небольшие правки (minor releases<ref>Меняется только последнее число в версии, то есть переход от версии 7.4.0 к версии 7.4.1.)</ref> не требуют никаких действий со стороны администратора БД.

Число пакетов, в описании которых упоминается PostgeSQL, довольно велико. Например, в Debian (Sarge) таких пакетов 182, что несколько меньше, чем число пакетов связанных с именем mysql (212), но превышает число упоминаний InterBase/Firebird (22), sqlite (50) и, естественно, Oracle (19). Это ни о чем не говорит, но корреляция, скорее всего, какая-то есть. К счастью, все 182 пакета ставить не обязательно – для Debian (Sarge) достаточно двух/трех:
# устанавливаются исполняемые файлы и файлы настроек
# необходимые для функционирования Базы Данных
> apt-get install postgresql
В случае подобной установки в обязательном порядке доставляется пакет PostgreSQL-client – базовый набор программ, которые можно ставить на клиентских машинах для удаленной связи с БД.

Если же, несмотря ни на что, хочется собрать все самостоятельно, то следует выполнить примерно следующую последовательность действий:
> wget ftp://ftp.postgresql.org/pub/source/v8.1.4/PostgreSQL-8.1.4.tar.bz2
> tar xvfj postgresql-8.1.4.tar.bz2
> cd postgresql-8.1.4
> ./configure
> make
> su
> make install
> adduser postgres
> mkdir /usr/local/pgsql/data
> chown postgres /usr/local/pgsql/data
> su - postgres
> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
> /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1
&
> /usr/local/pgsql/bin/createdb test
> /usr/local/pgsql/bin/psql test

Разберем то, что происходит, поподробнее. После того, как с помощью wget получен и распакован архив с исходными текстами, привычные команды ./configure и make позволяют осуществить сборку PostgreSQL. Установку (make install) следует производить под суперпользователем (su). После установки необходимо добавить пользователя postgres, от имени которого и будет запущен сервер postmaster. По умолчанию установка программы производится в директорию /usr/local/pgsql/. Для хранения файлов базы предлагается создать директорию /usr/local/pgsql/data. Данные должны принадлежать пользователю postgres (команда chown). В этой же директории хранятся и файлы настройки.

Дальнейшая настройка производится под пользователем postgres (su – postgres). С помощью команды initdb производится инициализация хранилища данных, а вслед за этим производится запуск сервера postmaster. Последние две строчки создают тестовую базу данных test (createdb) и проверяют, что к ней можно подсоединиться (psql). Если все прошло нормально, то должно появиться приглашение вида:
Welcome to psql 8.1.4, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help on internal slash commands
\g or terminate with semicolon to execute query
\q to quit

test=#
При установке стандартными средствами дистрибутива описанные выше действия выполняются автоматически, кроме последних двух строчек. В случае Debian (Sarge) при установке PostgreSQL можно указать, где именно расположить директорию с данными. По умолчанию все помещается в /var/lib/postgres/data. Для других дистрибутивов возможны вариации. Для выяснения подробностей следует изучить README. Например, в случае Debian, особенности пакета, связанные с README. Например, в случае Debian, особенности пакета, связанные с дистрибутивом, описаны в /usr/share/doc/postgresql/README.Debian.gz Ниже, если не указано специально, все действия выполняются для дистрибутива Debian (Sarge).

Для администрирования базы данных нет необходимости становиться root. Для этого можно настроить sudo (man sudo), то есть в файл /etc/sudoers (man sudoers) следует добавить примерно следующие строки:
# /etc/sudoers
Host_Alias HOME = localhost
User_Alias DBADM = “ваше имя, если Вы администратор базы данных”
Cmnd_Alias DB = /etc/init.d/postgresql
DBADM HOME = NOPASSWD: DB
DBADM HOME = (postgres) NOPASSWD: ALL
Файлы настройки принадлежат пользователю postgres, поэтому для их изменения необходимо иметь возможность заходить под этим пользователем:
> sudo -u postgres bash
> whoami
postgres
либо добавить себя в группу postgres и разрешить этой группе редактировать конфигурационные файлы в директории /etc/postgres(chgrp + chmod g+w).
{{Врезка|right|Ширина=200px
|Заголовок=К вопросу о номере порта
|Содержание=По умолчанию для создания TCP/IP соединения postmaster использует порт номер 5432. Если номер порта отличается от установленного по умолчанию, то postmaster должен быть запущен с ключом -p [номер порта].

Для выяснения этого достаточно выполнить:
<pre><nowiki>
> ps axw | grep
postmaster | grep -v grep
4181 ? S 0:00 /
usr/lib/postgresql/bin/
postmaster -D /home/
postgres/data
</nowiki></pre>
Номер порта может также храниться в переменной окружения $PGPORT..}}

Скрипт /etc/init.d/postgresql позволяет управлять процессом postmaster
> sudo /etc/init.d/postgresql
Usage: /etc/init.d/postgresql {start|stop|autovac-start|autovac-
stop|restart|autovac-restart|reload|force-reload|status}
> sudo /etc/init.d/postgresql status
pg_ctl: postmaster is running (PID: 10868)
Command line was:
/usr/lib/postgresql/bin/postmaster ‘-D’ ‘/home/postgres/data’
Этот же скрипт используется для автоматического запуска сервера при загрузке компьютера. От дистрибутива к дистрибутиву название инициализирующего скрипта может меняться.

После настройки сервера необходимо создать базу данных:
> sudo -u postgres createdb “имя БД”
CREATE DATABASE
и завести пользователя:
> sudo -u postgres createuser “имя пользователя”
Разрешить новому пользователю создавать базы? (y/n) n
Разрешить новому пользователю создавать пользователей? (y/n) n
CREATE USER
Для того чтобы пройти проверку при запросе на подключения необходимо, чтобы конфигурационный файл pg_hba.conf был настроен соответствующим образом. Например, чтобы можно было подключаться к базе данных под тем же именем, под которым вы работаете в системе, в pg_hba.conf должны присутствовать примерно следующие строки:
#/etc/PostgreSQL/pg_hba.conf
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
# connections by UNIX sockets
local all all ident sameuser
# All IPv4 connections from localhost
host all all 127.0.0.1 255.255.255.255 ident sameuser
Здесь в качестве метода идентификации используется метод ident sameuser<ref>Существует более либеральный метод проверки trust — в этом случае пускается кто угодно и под каким угодно пользователем. То есть метод «двери настежь» — некоторым нравится.</ref>. Создав пользователя в соответствии с текущей учетной записью, можно подсоединиться к PostgreSQL и начать общаться с сервером базы данных на его родном языке – SQL:
> psql “имя БД”

“имя БД”=> SELECT fio,number FROM fiodata, phonedata
“имя БД”=> WHERE fiodata.id=phonedata.id;

==Почему?==
Люди обычно работают с текстовыми файлами. Подавляющий объем структурированной информации до сих пор доставляется до нашего сознания через тест. Без помощи компьютера, в процессе ручного набора текста, информации производится не так уж и много. Необходимость базы данных в начале пути накопления личной информации не является очевидной. Все сделанное, в принципе, возможно окинуть взглядом.

==Почему БД?==
То, что создал один человек, другой человек, с высокой степенью вероятности, освоить в состоянии, но разобраться с наследием двух и более людей становится трудновато. А если это не наследие, а информация, идущая в реальном времени из многих (десятков, сотен, тысяч, миллионов) источников? Для начала все это надо куда-то сохранить, то есть необходимо надежное хранилище, по возможности ни от чего не зависящее.

И это еще полдела: данные надо как-то извлечь, причем не абсолютно все (иначе человеческий мозг в них утонет), а только нужные. Компьютеры пока еще не умеют надежно<ref>Удачные опыты по управлению курсором мыши или манипулятором уже зафиксированы, правда, для этого требуются имплантанты. Без имплантантов операторы могут передавать только самые простейшие команды, и вряд ли в ближайшее время ситуация кардинально изменится.</ref> считывать человеческие мысли, поэтому для начала необходимо нужные данные как-то пометить, и лучше это сделать в момент «укладки» в хранилище. То есть хранилище должно быть структурированным, причем структуру можно задавать извне до появления данных.

Когда данных немного – жить можно и так, оставляя ключевую информацию на обрывке листика, надеясь что он не затеряется. Обрывок листика слабо отличается от записи в каком-то файле. Текстовые утилиты типа grep существенно облегчают поиск информации, но всегда, в конце концов, настает момент, когда данных становится либо слишком много, либо они слишком часто изменяются и нужно вводить систему – Систему Управления Базой Данных или СУБД.

==Почему PostgreSQL?==
Когда я примерно шесть лет назад пытался понять, какую СУБД следует использовать для обеспечения эксперимента, в котором я участвую до сих пор, то выбора просто не существовало. Из свободных СУБД только PostgreSQL на тот момент обладал необходимой функциональностью. На сегодня вопрос выбора немного усложнился: подрос в хорошем смысле этого слова MySQL (в последней, 5-ой версии, говорят, наконец-то даже триггеры появились), были открыты исходные тексты проекта Firebird, в девичестве Interbase от фирмы Borland, да и «игрушечные» проекты типа SQLite тоже не лишены определенных преимуществ. Ну и, естественно, свет клином на открытых проектах не сошелся – тот же Oracle [бесплатно] предлагает свои СУБД для изучения. И все-таки я выбираю PostgreSQL – решение шестилетней давности меня не разочаровало. На редкость устойчивая к внешним воздействиям программа с абсолютно предсказуемым поведением. Даже те случаи, которые мне по неопытности показались «граблями», оказались «фичами».

Одной из основных целей, которая была поставлена при разработке PostgreSQL, является строгое соответствие стандартам. PostgreSQL поддерживает ANSI SQL–92, SQL–99 (SQL–2 и SQL–3, соответственно), а также многие из возможностей ANSI SQL:2003. Мало кому<ref>Возможно, что вообще никому. В большинстве случаев, следование стандарту заканчивается на вводном (entry) уровне SQL-92.</ref> удается похвастаться подобным соответствием стандартам.

В дополнение к стандартам, PostgreSQL поддерживает множество полезных расширений. Примером мелкого, но полезного расширения, не входящего в стандарт SQL, являются дополнения к условию для SELECT вида LIMIT/OFFSET<ref>Мне эти инструкции в свое время сильно облегчили жизнь, точнее, увеличили скорость выполнения нужных мне запросов</ref>, которые позволяют получить только указанные строки из результата запроса. PostgreSQL полностью поддерживает механизм транзакций (transactions), вложенные запросы (subselects), триггеры (triggers), представления (views), функциональные индексы, ссылочную целостность по внешнему ключу (foreign key referential integrity), изощренные типы блокировок (sophisticated locking) и многое другое.

К названию PostgreSQL обычно прибавляется слово «объектная», то есть полное наименование звучит как «объектно-реляционная база данных PostgreSQL». Пользователю предоставляются необходимые инструменты для создания новых типов данных, функций, операторов и своих методов индексирования. Подобные возможности позволяют работать с довольно нестандартными данными, например, с картографическими объектами – PostGIS (http://postgis.refractions.net/).

Размер базы данных, управляемой PostgreSQL, не ограничен, также нет ограничения и на число строк в таблице. Да и вообще, есть ли ограничения у этого чуда? Да, есть: ваша таблица не может быть больше чем 32 Тбайта, а число столбцов в таблице не может быть больше 250–1600, в зависимости от типа данных. Много это или мало? Зависит от задачи: я, например, как-то уперся в ограничение по числу столбцов, но скорее по неопытности, нежели по необходимости. Описанное выше верно для версии PostgreSQL 8.1.4. Возможно, в будущем будут сняты и эти ограничения.

Существует родные интерфейсы для работы с PostgreSQL из языков Java (JDBC), Perl, Python, Ruby, C, C++, PHP, Lisp, Scheme и всего, что может связаться через ODBC. PostgreSQL поддерживает хранимые процедуры, которые можно написать на множестве языков программирования, включая Java, Perl, Python, Ruby, Tcl, C/C++ и родном для PostgreSQL PL/pgSQL.

По результатам автоматизированного тестирования, проведенном в 2005 году (http://www.postgresql.org/about/news.363), в коде PostgreSQL было обнаружено 20 дефектов, что соответствует 1 ошибке на 39 тысяч строк кода. Для сравнения, аналогичное тестирование примерно в то же время выявило по одному дефекту на 10 тысяч строк кода в ядре Linux, а в MySQL одно проблемное место приходится на 4 тысячи строк кода. Это ни о чем не говорит, так сказать, мелочь, зато разработчикам и пользователям PostgreSQL приятно.

==Информация о...==
Книг по PostgreSQL, выпущенных на русском языке, относительно<ref>Например, относительно числа книг по PHP+MySQL.</ref> немного, но они есть, и количество их будет расти. Эта область технических знаний не так популярна, как следовало бы. Очевидно, что в будущем без надежных хранилищ данных будет непросто управляться со все возрастающим потоком информации.

С другой стороны, наличие отличной документации (в том числе и русскоязычной) позволяет достаточно безболезненно «войти в тему». Вполне можно обойтись и без специфичных для PostgreSQL возможностей, а для изучения основ SQL годится любая нормальная книга, коих довольно много. Для введения вполне сгодится «SQL» от Мартина Грабера (издательство «Лори», 2003). Собственно говоря, хватит и стандартной документации, которая идет в дистрибутиве.

Основной сайт PostgreSQL находится по адресу: http://www.postgresql.org. Там расположено первичное хранилище обширной документации, в которой есть фактически вся «мудрость мира», имеющая хоть какое-то отношение к PostgreSQL – надо только уметь читать.

По адресу http://www.linuxshare.ru/postgresql/ представлена русскоязычная версия сайта. Там же можно найти информацию о русскоязычном тематическом списке рассылки pgsql-ru-general-owner@postgresql.org. Список не сильно активный, но если хочется перемолвиться о «subj» по-русски – вполне сгодится.

==Примечания==
<references />