Специалисты по программированию СУБД, оцените придуманную мной схему

программирование базы данных postgresql триггеры

Есть программа, которая умеет выводить данные по ODBC.

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

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

Одно время у меня была идея написать собственный ODBC драйвер, который перехватывал бы вывод из программы-источника, но мне это показалось малопродуктивной идеей.

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

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

С какими трудностями или ограничениями могу я столкнуться?

В день у меня должно накапливаться порядка 20000 записей.

Для любопытных: "программа-источник" называется QUIK, но это не имеет отношения к существу вопроса.
Ответы:
Тоже именно с PostgreSQL не работал, но обычно такие вещи решают простым способом:
Триггер на таблице, в которую записываются данные генерирует событие базы данных. Есть какое-то приложение, которое "подписано" на получение этого события. Таким образом оно уведомляется о произошедшем событии.
а нафига с БД заморачиваться? открыл сокет/пайп и одной прогой фигачишь в него данные, а другой слушаешь и читаешь...
2 neiro : программа-источник не умеет сокеты открывать.
Все, что она умеет - писать в заданный DSN по ODBC .
MySQL конечно же рулит по сравнению с Oracle, "отношение к которому скептическое" - ну юморист...
JSerge, Ваша конкретная рекомендация "перейти на Oracle и не париться?".
Можно и подробнее =)
Во многих базах данных (в каждой СУБД реализовано по-разному) есть такое понятие как событие, подписка на событие, отписка от события.
Вы создаете свое уникальное событие (или выбираете подходящее, стандартное), и в нужный момент его "широковещательно" отправляете жить в мир (например, в вашем случае, с помощью триггера на вставку данных).
Приложения, "подписанные" на получение этого события, будут уведомлены о том, что вот оно... свершилось.
Честно признаюсь, с PSQL не работал. Но нужно копать в эту сторону.
Есть такое в PSQL =)
"Копать в сторону Notify, Listen, Unlisten.": [1]. Далее есть описание.


16 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

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

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.