регистрация действий пользователя в базе данных

← →
jenya_d (2004-01-27 14:45) [0]

Доброго времени суток профи!!!
Подскажите пожалста как лучше организовать регистрацию действий пользователя по категориям в базе данных IB55?
Суть задачи: есть таблицы
Table1(id int(PK), datreg date, zarp numeric(9,3), kons char(1)),
Table2(id int(PK), id_dop int(PK), datreg date, zarp numeric(9,3))
и
Narush(id int, id_nar int)

Table2 связана с Table1 по полю id, Narush связана с Table1 по полю id.

Пользователи добавляют в них записи. Необходимо регистрировать изменение пользователями параметров (zarp в таб. Table1, zarp в таб. Table2, id_nar, kons) на дату введенную в datreg, чтобы потом делать анализ ввода этих параметров на даты, с сохранением истории ввода.

Заранее благодарен.

← →
Карелин Артем (2004-01-27 14:59) [1]

Ну эта.. Триггер пиши на изменение:
...
declare variable i integer;
begin
if old.какое-то_поле=new.какое-то_поле then i=1;
if old.какое-то_другое_поле=new.какое-то_другое_поле then i=2;
...
Ну а сохранить в каком-то поле какой-то таблицы значение i надеюсь проблем не составит?

← →
HSolo (2004-01-27 15:06) [2]

Можно, например, завести таблицу-протокол с полями:
- юзер
- операция (добавление, коррекция, удаление)
- дата операции
- имя таблицы, старые/новые значения полей - по вкусу
и заполнять ее в триггерах

← →
jenya_d (2004-01-27 15:31) [3]

>HSolo © (27.01.04 15:06)
типа такого я уже реализовывал по началу, тоже была табличка-протокол в ней фиксировались: юзер, таблица, операция, дата операции, код записи и нужного результата я не получил (правда не сохранял старые/новые значения полей - посчитал слишком большим расточительством).

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

← →
Карелин Артем (2004-01-27 15:40) [4]

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

← →
stud (2004-01-27 16:09) [5]

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

← →
jenya_d (2004-01-27 16:10) [6]

>Карелин Артем © (27.01.04 15:40)
Изменение несольких полей считалось несколькими изменениями.

← →
jenya_d (2004-01-27 16:11) [7]

stud © (27.01.04 16:09)>
Если можно подробнее

← →
HSolo (2004-01-27 17:12) [8]

> нужного результата я не получил
Вот отсюда, если можно, поподробнее. Какой результат Вам нужен?

← →
jenya_d (2004-01-27 17:30) [9]

>HSolo © (27.01.04 17:12)
мне нужно чтобы за любой период времени по каждому пользователю (или всем вместе) по определенным параметрам заданным мной можно было получить анализ того сколько параметров занес тот или иной пользователь. Но чтобы даже если правка будет осуществляться "задним" числом в архиве информация была бы правильно сохранена, чтобы данные поднятые за старые промежутки времени в любой момент были бы одинаковыми и чтобы не случалась такая история: количество введенных параметров по записям больше чем вего записей на эту дату.

← →
HSolo (2004-01-27 17:37) [10]

Тогда Ваша структура таблицы-протокола должна подойти, разве что добавить еще "вид операции" (добавление / коррекция). Как Вы заполняли протокол? Как делали выборку для анализа? Что такое "архив", где и как он хранится?

← →
paul_k (2004-01-27 17:44) [11]

2 jenya_d
простите, не совсем ясно, что Вам нужно получить...
протокол действий юсера? то есть какого числа какую запись во сколько ковырял?
или некий журнал изменений - данные в таблице на дату/время/усера.
чтоб видно было что этот усер наковырял, и все его ковыряния можно было безболезненно откатить?

← →
stud (2004-01-27 17:52) [12]

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

← →
jenya_d (2004-01-28 09:42) [13]

>HSolo © (27.01.04 17:37)
>Как делали выборку для анализа? Что такое "архив", где и как он хранится?

Выборка делалась так:

select код_юзера, count(id) from таблица-протокол where дата_операции >= дата_нач and дата_операции <= дата_оконч and код_парам = интересующий_параметр group by код_юзера

Архивом я называл таблицу-протокол.

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

>paul_k © (27.01.04 17:44)
не то и не другое, см. выше

>stud © (27.01.04 17:52)
это не то что надо, слишком много инфы, причем делать это должна моя прога во время работы и пользователи у меня свои, а не IBэйсовские

← →
paul_k (2004-01-28 10:04) [14]

по моему странная задача.
решается либо тригерром на добавление записи в таблицу, либо добавлением записи через ХП.
Так как дата обычно пишется вместе со временем, то дублирование записае в протоколе мало вероятно. Поэтому можно ограничится только добавлением записи, а в выборке показывать последнюю запись относительно текушей даты/времени (или все)
Можно создать доп справочник где хранить имя таблицы,имя поля, описание параметра. Добавлять к протоколу ID из этой таблицы
Но в этом случае сколько параметров поменял пользователь столько записей и будет.
Если добавить ещё таблицу для связи ID протокола ID Параметра то можно эффективно получать последнее изменение (все изменения) и при желании список измененных параметров

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

← →
HSolo (2004-01-28 10:15) [15]

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

Может, подойдет пара полей: "имя (или какой-нибудь код) таблицы" + "ID записи в таблице" ?

> заполнение протокола осуществлять не просто простым добавлением новой записи при добавлении записи пользователем, а с анализом: есть ли на такую запись, на добавляемую дату, на фиксируемый параметр данные в таблице-протоколе? Если нет, то добавить новую запись, а если есть, то проверить пользователя и при необходимости его сменить

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

← →
jenya_d (2004-01-28 10:46) [16]

>paul_k © (28.01.04 10:04)
спасибоза интересные предложения, но у меня задача в принципе абстрагированная от таблиц, полей, записей. Есть нужные параметры (прием вещи, регистрация вещи, установка нач. стоимости, установка конечной стоимости и т.п.) и по ним ведется фиксация привязанная к дате, юзеру и идентификатору определяющему к какой вещи относятся данные

>HSolo © (28.01.04 10:15)
>Может, подойдет пара полей: "имя (или какой-нибудь код) таблицы" + "ID записи в таблице" ?

я думал о том-же, но в другом свете: кодирование в одном поле - код_зап_таб1*1000+код_зап_связ_таб2. Правда как туда запихнуть код записи из третьей связанной со 2-ой таблицы - пока не придумал

>Т.е. под "добавлением" Вы подразумеваете либо добавление записи в таблицу, либо коррекцию существующей записи другим пользователем?

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

← →
paul_k (2004-01-28 10:51) [17]

> Есть нужные параметры (прием вещи, регистрация вещи, установка
> нач. стоимости, установка конечной стоимости и т.п.)

и это не поля таблиц?

← →
jenya_d (2004-01-28 11:33) [18]

>paul_k © (28.01.04 10:51)
>и это не поля таблиц?

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

← →
HSolo (2004-01-28 11:42) [19]

> я подразумеваю что юзер либо занес по этой записи нужное мне значение или просто ее добавил

Иными словами, "занес по этой записи нужное значение" = "откорректировал существующую запись" ?
Тогда у Вас кол-во введенных параметров (по протоколу) = кол-во добавленных записей + кол-во коррекций существующих записей.

Тогда естественно, что

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

← →
jenya_d (2004-01-28 12:11) [20]

Все спасибо всем. Разобрался вроде в чем проблема.

регистрация действий пользователя в базе данных Найти похожие ветки