iBase.ru Forum

Родилась такая задача, надеюсь кто-нить подкинет идею как её красиво решить
Есть рабочая база (FB2) довольно скромного размера. правда довольно много логики на триггерах висит, так что забывать о производительности не удаётся.
Есть идея - вести лог изменений базы. причём никаких сравнений не проводиться - по логике выделяется пару десятков записей из 2-4 таблиц, который мона смело сейвить в журнал как некую непротиворечивую сущность
И есть параноя - ведение журнала автоматом (в смысле без участия клиентских прог, только за счёт архитектуры базы/консольных утилит или библиотек на сервере) в отдельной базе на произвольном сервере и в рамках текущей транзакции.
Другими словами юзверь типа закончил некий сеанс и грит "коммит, m^я". при этом происходит запись в базу-журнал на удалённом сервере, и обязательном условием успешного коммита является коммита данных в журнале.
fbcopy в основном не подходит из-за описанной паранои с комитами.
вроде всё жду идей обсчественности, заранее благодарен

Сперва определись, что такое "лог" в твоём понимании.
Теория и физика.
Потом почитай раздел "Репликация" в документации на этом сайте.
А уж когда возникнут какие-то конкретные вопросы - возвращайся

WildSery писал(а):Сперва определись, что такое "лог" в твоём понимании.

Определился - каждая "запись" лога это документ, отредактированный пользователем, состоящий из ~10-20 записей из ~2-4 различных таблиц рабочей базы

WildSery писал(а):Теория и физика.

знал бы практику не спрашивал бы

WildSery писал(а):Потом почитай раздел "Репликация" в документации на этом сайте.

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

WildSery писал(а):А уж когда возникнут какие-то конкретные вопросы - возвращайся

Обращаюсь - как в рамках текущей транзакции передать набор данных в другую базу данных на произвольном сервере? причём передать средствами сервера (родными или моими) по некоему сигналу с клиентского приложения.
каким образом мне здесь поможет репликация?
вообще по сути гетерогенные запросы всё прекрасно решили бы
поэтому нужно как-то их сыммитировать либо придумать какой-либо другой механизм

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

ulir писал(а):как в рамках текущей транзакции передать набор данных в другую базу данных на произвольном сервере? причём передать средствами сервера (родными или моими) по некоему сигналу с клиентского приложения.

Без клиентской части или извращений типа UDF пишущей в другую базу - никак.
Встречный вопрос - зачем журнал должен быть в другой базе?

ulir писал(а):причём лог должен быть записан ДО комита основной транзакции

Нет, сынок, это фантастика (С). Точнее, он может быть записан до коммита, аж двумя способами. Первый - в таблицу-лог в той же базе, которую после коммита может вычитать заинтересованное приложение и сложить куда угодно. Но только после. Второй - во внешнюю таблицу-файл на том же сервере. Однако, тут ты не узнаешь, завершилась изменявшая транзакция коммитом или изменения потом откатились.

ulir писал(а): Обращаюсь - как в рамках текущей транзакции передать набор данных в другую базу данных на произвольном сервере? причём передать средствами сервера (родными или моими) по некоему сигналу с клиентского приложения.
вообще по сути гетерогенные запросы всё прекрасно решили бы

Взаправди? Сдаёццо мне, что ты, отрок, не знаешь значения произносимого тобою заклинания... Вот твоё приложение действительно может это само сделать, для этого тебе надобно ознакомиться с понятием двухфазного коммита (2PC).

WildSery писал(а):Без извращений типа UDF пишущей в другую базу - никак.

Именно извращений. Те же йацы, что и external table, только в профиль.

WildSery писал(а):Без клиентской части или извращений типа UDF пишущей в другую базу - никак.

а чем UDF извращение? не считая необходимости таскать dll и собсно написать иво

WildSery писал(а):Встречный вопрос - зачем журнал должен быть в другой базе?

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

Merlin писал(а):Нет, сынок, это фантастика (С). Точнее, он может быть записан до коммита, аж двумя способами. Первый - в таблицу-лог в той же базе, которую после коммита может вычитать заинтересованное приложение и сложить куда угодно. Но только после. Второй - во внешнюю таблицу-файл на том же сервере. Однако, тут ты не узнаешь, завершилась изменявшая транзакция коммитом или изменения потом откатились.

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

Merlin писал(а):Взаправди? Сдаёццо мне, что ты, отрок, не знаешь значения произносимого тобою заклинания...

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

Merlin писал(а):Вот твоё приложение действительно может это само сделать, для этого тебе надобно ознакомиться с понятием двухфазного коммита (2PC).

двухфазный комит это замечательно, но для этого нужно
а) серверная часть или б) участие клиентское программы
оба варианта не устраивают. потому и вопрос задавал, как без них обойтись можно, только за счёт FB али сопутствующих утилит и т.д. в самом крайнем случае - сервис на сервере с базой.

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

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

ulir писал(а): Для папы ещё раз - лог в той же базе не интересует, случай известный, с ним грешные и сами справимся. плюс не вижу концептуальной разницы между вариантом один и два - тоже самое вид с боку.

Папа понял. Печально два раза. И что намерен бороться с природой, и что не видишь разницы. Хотя, папе в общем-то пофиг, природе не убудет.

ulir писал(а): откатиться изменявшая транзакция может только по системным ошибкам,

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

ulir писал(а):

Merlin писал(а):Взаправди? Сдаёццо мне, что ты, отрок, не знаешь значения произносимого тобою заклинания...

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

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

Merlin писал(а):Твои юзера в состоянии пипкодавством обогнать бота, получающего эвент на коммите и тут же вычитывающего и зачищающего внутрений лог? Сымаю перед ними шляпу...

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

Merlin писал(а):Папа понял. Печально два раза. И что намерен бороться с природой, и что не видишь разницы. Хотя, папе в общем-то пофиг, природе не убудет.

а) разницы не вижу в разрезе предложенной проблемы
б) с природой никогда не соревновался и не собираюсь, потому и вопрос задал, думал может кто предложит природное решение

Merlin писал(а):Ааа... мосье пишет программы без ошибок и системных у него тоже не случаеццо и сетка не ложиццо периодицки... Ну что ж, кто-то из юзеров пойдёт под расстрел за изменения, в которые его будут тыкать носом в логе, и которых он в базе на самом деле так и не сделал. В конце концов, юзером больше, юзером меньше...

а) есть, случаеццо, ложиццо. и что? это как-то приблизило к ответу?
б) так вот о решении, которое обеспечит надёжность и целостность данных я и спрашиваю. как гарантировать запись в лог и как эту запись вообще провести.

Merlin писал(а):Ах, ещё и в процедуууре гетерогенные подавай... Да к базе на другом серваке... свежо, оригинальненько. И главное, очень, очень надёжно с точки зрения работы самого сервера... Ну-с, ждите.

я говорил что это возможное или хорошее решение???
Merlin, не искушай флудом, может о деле что-нить скажешь? например, о udf варианте. был бы рад услышать в чём извращённость.

Merlin, не искушай флудом, может о деле что-нить скажешь?

это ты кончай флудить. разберись сначала с транзакциями и евентами, и как они работают. А потом будешь думать.

Насчет udf я могу сказать.

1. коннект к другой БД из udf это изврат, ненадежно, и не гарантируется. Особенно если сбойнет соединение. в UDF обычно пишется обработка входных параметров, и передача результата на выход. A+B, Pos(A, B), и так далее. Никаких действий, которые могут вызвать паузу в работе udf, в ней выполнять нельзя.

2. вызов udf также не подвержен транзакционности. после вызова нелья узнать, чем была транзакция завершена, и вообще была ли завершена.

Дальше. Если ты читал про репликацию, то это не "синхронизация" баз. Реплицировать можно все что угодно, и как угодно. В том числе и по событиям.
Если же тебе надо делать лог по нажатию кнопки клиента, ну так и сделай это. чем тебе посыл изменений через клиента не нравится?
В общем, флуд натуральный.

ulir писал(а):а) юзеру могут случайно или намеренно эту базу грохнуть. как файл. вероятность что они грохнут два файла одновременно близка к нулю.
б) не все юзеры вообще о её существовании должны знать

а) АГА ЩАЗЗЗ. Файл БД как файл по сети и не должен быть доступен, если админ разрешил доступ к файлу по СМБ/ФТП или еще как так он сам себе злобный буратина.
б) юзер вообще не должен знать где лежит база, даже если он и знает что БД физически лежит на пятом сверху сервере в стойке, то в серверной ему одн фиг делать нечего, и это сокровенное знание ему ничего не даст. Про доступ по сети см. пункт а.

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

в общем идея вышла абсурдная и велосипедная.
через клиента будет на порядок проще/веселее.
кстати с сеткой у клиента полуанархичное состояние,
а админить её за спасибо тоже желания нет.
думаю топик исчерпан. спасибо всем кто ответил.