모티프

나는 이전의 LAMP 시스템으로 사건 처리에 팩스를 보내고 싶다

이벤트 상점 신설이 쉽지 않다

이벤트 스토어의 내용을 참조 시스템에 투영할 준비를 해야 한다

결과 일치성 고려 필요

규모가 큰 시스템은 아니다

이런 이유로 나는 활동을 포기했다.
따라서 도메인 이름 활동도 다양한 활동을 할 수 없다
나는 깊이 생각하지 않았다.
하지만 아래의 방법이라면 사건 처리를 할 수 있지 않겠는가?나는 이렇게 생각하고 투고했다.

선결

RDBMS의 트리거 기능을 사용하면 되지 않습니까?

프로비저닝

LAMP이지만 취향에 따라

L = linux

A = apache

M = postgresql

P = php

라는 생각이 들었다.

둘 사이의 거리를 넓혀 보아라

이런 느낌으로 각 처리에서 각각 테이블 위에서 크루드를 진행하는 느낌. 구성안
Postgresql의 트리거 기능를 사용하면 RDBMS를 직접 사용하여 이벤트 처리를 할 수 있을 것 같습니다.
다른 주요 RDBMS에도 트리거 기능이 있다고 생각합니다.
예를 들어 이벤트스토어로 다음 테이블을 준비합니다.

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE TABLE public.events
(
    event_id uuid NOT NULL DEFAULT uuid_generate_v4(),
    event_name text COLLATE pg_catalog."default" NOT NULL
    version integer NOT NULL,
    data json NOT NULL DEFAULT '{}'::json,
)

다음 함수를 트리거 함수로 정의하기

CREATE OR REPLACE PROCEDURE book_added(version int, data json) AS $book_added$
BEGIN
-- イベントに付随するjsonを用いてinsertなりupdateなりdeleteなりを行う.
END;
$book_added$
LANGUAGE plpgsql;

CREATE OR REPLACE PROCEDURE book_borrowed(version int, data json) AS $book_borrowed$
BEGIN
-- イベントに付随するjsonを用いてinsertなりupdateなりdeleteなりを行う.
END;
$book_borrowed$
LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION event_exec() RETURNS trigger AS $event_exec$
BEGIN
  CASE NEW.event_name -- イベント名で振り分け
  WHEN 'book.added' THEN -- 例えば"本を追加した"
    CALL public.book_added(NEW.version, NEW.data);
  WHEN 'book.borrowed' THEN -- 例えば"本を借りた"
    CALL public.book_borrowed(NEW.version, NEW.data);
  ELSE
    RAISE EXCEPTION 'not found : %', NEW.event_name;
  END CASE;
  RETURN NEW;
END;
$event_exec$
LANGUAGE plpgsql;

등록 트리거

CREATE TRIGGER event_exec
    AFTER INSERT
    ON public.events
    FOR EACH ROW
    EXECUTE PROCEDURE public.event_exec(\x);

이후 이벤트스토어에서 인스타그램만 하면 이벤트 내용에 따라 표를 업데이트한다.
이게 좋은 점은요.

터치 참조 시스템의 처리가 필요 없음

업데이트 시스템의 처리를 한 번에 변경할 필요가 없음

일관성 있는 타임라인

주요 이벤트에 대한 비즈니스 지식 고려 가능

생각할 수 있어.
거꾸로 말하면 나쁜 점은

이벤트 저장 장치의 내용을 참조 시스템의 프로젝터 부분에 투영하여 PL/pgSQL

이 되다
가명

터치 참조 시스템의 처리가 필요 없다

원래 정의된 테이블은 최신 상태로 유지되며 참조 시스템은 그대로 유지됩니다.
모든 업데이트 시스템이 이벤트 정리를 대체할 때 표의 최적화와 축소를 논의할 수 있습니다.

시스템 업데이트 작업은 한 번에 변경할 필요가 없습니다.

원래 업데이트 시스템의 처리는 표를 직접 CUD로 처리한다.
업무 지식을 정리하는 곳에서
- 이벤트 삽입->이벤트store-CUD->테이블
로 수정할 수 있습니다.
최종적으로 모든 업데이트 시스템이 이벤트 처리 시스템으로 바뀌면 이벤트 저장지를 이벤트 상점으로 변경하는 것을 논의할 수 있다.

결과 일관성 있는 타임라인은 무한히 낮음

이른바 사건 처리의 구성
- 이벤트 삽입 -> 이벤트 스토리지 - 이벤트 알림 -> 참조 RDBMS- 이벤트 테스트테이블에 반영 -> 테이블
일정한 타임라인이 나타납니다.
그러나 트리거 정의를 사용하면 같은 자원에 거래를 붙이면 모든 트리거를 봉쇄한다.
사건 처리를 고려할 때 어느 정도 번거로운 결과의 통합성을 무시할 수 있다.

주요 활동에서 업무 지식을 고려할 수 있다

특별한 활동 처리를 하지 않더라도 주요 활동에서 업무 지식을 고려할 수 있다고 생각합니다.
사건이 나뉘어도 그 실체의 조작 역사는 남지 않는다
결과는 각 테이블을 직접 업데이트할 수 있는 환경에서
A 했어요. -> 테이블 업데이트.
B-> 업데이트 테이블
C에서 -> 업데이트 테이블
보다
A가 한 B가 한 C가 한 내용을 종합하여 ->표 업데이트
나는 이렇게 하는 것이 좋지 않다고 생각한다. 도메인 이름 활동을 탐구하기는 매우 어렵다.
- 이벤트 삽입->이벤트store-CUD->테이블
이동

예를 들면 A, B, C

를 고려할 수 있습니다.

이벤트 A 발생 시 xx 변경

따로 생각해도 되겠습니까?

참조 시스템의 프로젝터 섹션에 이벤트 스토어 내용 투영 PL/pgSQL

postgres입니다.

PL/pgSQL

PL/Tcl

PL/Perl

PL/Python

에서

이벤트 A 발생 시 xx 변경

설치 섹션이 분리되었습니다.
응, 이 부분은 업무 지식이 아니라 순수하게 분배와 전환 처리를 하면 돼.

총결산

탁상공론병의 공론으로 죄송하지만, 트리거를 사용하면 RDBMS로도 사건 정리를 할 수 있을 것 같아 투고했습니다.
앞으로 주변 사람들에게 폐를 끼치지 않는 선에서 실천하고 싶다.
이 방법에 대해 매우 큰 결점이 있을 수 있으니 그때 지적해 주십시오.