Событийно-оринтированная база данных

man триггеры

Что-то вроде этого и имелось ввиду. Только было бы замечательно если клиент мог слушать на события.

Мне вообще незачем, просто интересуюсь.

смысл где?

смысл где?

даже обычной морде для администрования БД это не помешает

я имею ввиду, это именно то что должна уметь бд искаропки? иначе в чем вопрос вообще?

В redis что-то такое есть

ЕМНИП, MySQL умеет кроме обычных триггеров ещё и запускать по событию внешние комманды/приложения, правда, только от прав пользователя, под которым работает сам БД. По дефолту выключено.

http://dev.mysql.com/doc/refman/5.5/en/faqs-triggers.html#qandaitem-B-5-1-10

Ну это уже извращение. Нужно что-то нормальное.

Что-то есть. Какие каналы, подписки и отписки на них. Что-то узкоспециализированное наверное.

короче давай переходи к чему ты клонишь, писать будешь?

Только было бы замечательно если клиент мог слушать на события.

Это легко соорудить на триггерах в специальной схеме, где у клиента есть права создавать таблицы с триггерами и регистрировать их (записывать их названия) в системную, по которой будет вестись рассылка событий.
Только это никому не надо, всегда есть более кошерные механизмы.

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

допустим финансовая биржа

Они даже транзакций не используют.

Для некоторых бд (например, оракл) можно написать процедуры на java/c, которые работают на стороне бд и могут делать, что угодно (например, почту слать, или послать ивент клиенту по различным протоколам), но это редко когда бывает оправданно.

http://citforum.ru/database/oracle/kyte/19.shtml

«Хранимые процедуры на языке Java» для Oracle Db. Если действительно надо, а не просто бла-бла :)

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

Короче как я понял нормального механизма в БД для уведомления клиентов просто нету.

Чтобы можно было написать вот так:

select_db(«messages»).set_event(NEW_TABLE_ROW, callback);

Тогда если произойдёт добавление нового поля в таблицу, БД отошлёт клиенту что вот, добавлено новое поле и это обработается в callback'е(впрочем асинхронность в клиенте это просто пример). БД должна _САМА_ отослать уведомление клиенту.

Можно было бы так ещё онлайн игры делать. Например если кто-то изменил позицию в пределах 2 виртуальных км, а она пусть всегда записывается в БД, отослать уведомление игровому клиенту что нужно перерисовать игроков.

Выглядило бы это так:

statement = db_intractive_lambda { if contain_other_player(pos_player(80, 2))} /* 80 - id текущего игрока, 2 - растояние вокруг которого искать */ select_db(«players»).set_event(statement, callback);

db_intractive_lambda - функция которая исполняется всегда сразу после обновления данных.

это все задачи, конечно же, для бд маштабируемость тут тоже на ура влажные мечты короче

В будущем наверное БД будут такими. Не будет особых абстракций типа: данные <--> сервер + возможность полноценно программировать БД.

бедная база данных, в которой это могло бы работать.

повторяюсь, влажно...

в firebird есть события, клиент может быть на них подписан.

такое есть в Postgresql: если надо реагировать на событие: триггеры и триггерные функции. если надо, чтобы клиенты слушали уведомления, то для есть Notifications.

Причем триггерные функции можно писать, помимо plsql и c, на plpyhton.

postgresql должен мочь. А БД сама по семе добавляет данные? Зачем вообще именно она должна уведомлять что добавились данные? Чую кривую архитектуру.

Почему ещё никто не написал про JMS? Те же Oracle/DB2 могут из триггеров слать JMS, слушать их можно много чем.

Юзай H2, она embedded, можешь встроить в свое приложений (или отдельный сервис) и она может вызывать в качестве триггера ваш код. Он уже может передать event куда надо

Почему ещё никто не написал про JMS?

Видимо, все отправляют сообщения еще в приложении, на уровне модели. И о таком изврате даже не думают.

Видимо, все отправляют сообщения еще в приложении, на уровне модели.

this

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

http://www.postgresql.org/docs/9.0/interactive/sql-listen.html

Couchdb умеет notifications, например. Хотя это не совсем то.