— Бухаров А.В. 2019/06/17 08:58

— Бухаров А.В. 2019/06/17 09:04

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

ALTER TABLE EVENTS
ADD ANALIT INTEGER\\ update RDB$RELATION_FIELDS
set RDB$DESCRIPTION = 'Результат аналитики событий'
where (RDB$RELATION_NAME = 'EVENTS') and
(RDB$FIELD_NAME = 'ANALIT')

INSERT INTO CARDTYPE (ID, NAME, DESCRIPTION) VALUES (1, 'RFID', 'Карта EM-marine');
INSERT INTO CARDTYPE (ID, NAME, DESCRIPTION) VALUES (2, 'FP', 'Отпечаток пальца');
INSERT INTO CARDTYPE (ID, NAME, DESCRIPTION) VALUES (3, 'ШК', 'Штрих-код');
INSERT INTO CARDTYPE (ID, NAME, DESCRIPTION) VALUES (4, 'ГРЗ', 'Государственный регистрационный знак а/м');
COMMIT WORK;

INSERT INTO DEVTYPE_CARDTYPE (ID_DEVTYPE, ID_CARDTYPE, ID_DB) VALUES (1, 1, 1);
INSERT INTO DEVTYPE_CARDTYPE (ID_DEVTYPE, ID_CARDTYPE, ID_DB) VALUES (5, 4, 1);
INSERT INTO DEVTYPE_CARDTYPE (ID_DEVTYPE, ID_CARDTYPE, ID_DB) VALUES (6, 1, 1);
INSERT INTO DEVTYPE_CARDTYPE (ID_DEVTYPE, ID_CARDTYPE, ID_DB) VALUES (4, 2, 1);
INSERT INTO DEVTYPE_CARDTYPE (ID_DEVTYPE, ID_CARDTYPE, ID_DB) VALUES (4, 1, 1);

COMMIT WORK;

INSERT INTO DEVTYPE (ID_DEVTYPE, ID_DB, NAME, STANDALONE) VALUES (1, 1, 'Контроллеры Артонит/Адемант', 1);
INSERT INTO DEVTYPE (ID_DEVTYPE, ID_DB, NAME, STANDALONE) VALUES (2, 1, 'Контроллеры Артонит (резерв)', 1);
INSERT INTO DEVTYPE (ID_DEVTYPE, ID_DB, NAME, STANDALONE) VALUES (3, 1, 'UHF RFID контроллеры', 1);
INSERT INTO DEVTYPE (ID_DEVTYPE, ID_DB, NAME, STANDALONE) VALUES (4, 1, 'Biomrteical', 1);
INSERT INTO DEVTYPE (ID_DEVTYPE, ID_DB, NAME, STANDALONE) VALUES (5, 1, 'Система распознавания ГРЗ', 1);
INSERT INTO DEVTYPE (ID_DEVTYPE, ID_DB, NAME, STANDALONE) VALUES (6, 1, 'Артонит в режиме он-лайн', 0);

COMMIT WORK;

"C:\Program Files (x86)\Firebird\Firebird_1_5_6\bin\gbak.exe" -b -v -ig -g "127.0.0.1:C:\Program Files (x86)\Cardsoft\DuoSE\Access\SHIELDPRO_REST.GDB" C:\service\SHIELDPRO_REST_%date%.FBK -USER sysdba -PASSWORD temp 

ALTER TABLE EVENTS ADD ANALIT INTEGER

1. Обновить саму базу данных до последней версии.
2. записать данные в таблицу CARDTYPE.
3. записать данные в таблицу DEVTYPE_CARDTYPE.
4. в таблице card всем пользователям установить категорию доступа NULL (update card set … = null).
5. Очистить содержимое таблицы cardidx.
6. Очистить содержимое таблицы cardindev.

База обновлена и готова к проверке и последующему использованию по назначению.

Удаление - процесс опасный, поэтому я привожу пример select.
При необходимости удаления следует select * заменить на delete.

select * from events e
where e.datetime>CURRENT_DATE-2

либо

 select * from events e where e.datetime >DATE'today' - 2

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

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

1. Ввести типизацию событий, для каждого типа указать срок хранения,
2. Административно определить какое событие к какому типу относится,
3. подготовить необходимые SQL запросы, чтобы обеспечить удаление событий в соответствии с определенной политикой,
4. в Назначение задания внести необходимые настройки, чтобы сформированные запросы запускались ежедневно в начале суток.

 Удаление указанных событий старше 30 дней
delete from events e 
where e.datetime < CURRENT_DATE-14
and e.id_eventtype in (0, 46, 49)

 Удаление указанных событий старше 30 дней
delete from events e
where e.datetime < CURRENT_DATE-45
and e.id_eventtype in (17, 18, 19, 32, 33, 34, 51)

 Удаление указанных событий старше 30 дней
delete from events e
where e.datetime < CURRENT_DATE-60

— Бухаров А.В. 28.02.2020 08:51
Т.к. в результате нам требуется выполнение всех запросов за один раз, то резонно их собрать в одном файле.
Для анализа состояния базы данных хорошо бы знать и количество событий в журнале, и их распределение по событиями. Все это реализуется в одном файле (см. ниже).
В лог-файле будет отображено время и окончания работы скрипта, количество событий после удаления событий и статистика по событиям:

 delete from events e
where e.datetime < CURRENT_DATE-45;
commit;;

delete from events e where e.datetime < CURRENT_DATE-5 and e.id_eventtype in (0, 46, 49, 53, 54, 57, 58); 
commit;;

delete from events e where e.datetime < CURRENT_DATE-5 and e.id_eventtype in (17, 18, 19, 32, 33, 34, 51);
commit;;

select count (*) from events;
commit;;


 select distinct e.id_eventtype, et.name, count(e.id_event) from events e
join eventtype et on et.id_eventtype=e.id_eventtype
group by e.id_eventtype, et.name ;
commit;;

select distinct e.analit, count (*) from events e
			where e.analit is not null
			and e.datetime> CURRENT_TIMESTAMP-1
			group by e.analit;
commit;;			

Вывод информации о типах событий и их количество в базе данных.

 select distinct e.id_eventtype, et.name, count(e.id_event) from events e
join eventtype et on et.id_eventtype=e.id_eventtype
group by e.id_eventtype, et.name

Для запрета удаления пользователя Администратор необходимо выполнить указанный ниже скрипт.

/******************************************************************************/
/***               Generated by IBExpert 06.03.2020 16:28:50                ***/
/******************************************************************************/
SET SQL DIALECT 3;
SET NAMES WIN1251;
SET TERM ^ ;
CREATE TRIGGER PEOPLE_MET_DELETE_ADMIN FOR PEOPLE
ACTIVE BEFORE DELETE POSITION 0
AS
begin
  if (old.id_pep = 1) then exception deletenotallowed;
end
^
SET TERM ; ^

Список запланированных доработок.