AppMaster는 데이터베이스 작업을 위한 광범위한 기능을 제공합니다. 예를 들어 검색 블록을 사용하면 필요한 데이터를 찾아 관련 테이블을 첨부하고 올바른 순서로 정렬하는 등의 작업을 할 수 있습니다. 그러나 특정 상황에서는 이것이 충분하지 않을 수 있으며 SQL Exec 블록이 나타납니다. 구조. SQL의 모든 기능을 사용하여 모든 데이터베이스 쿼리를 실행할 수 있습니다.
책 카탈로그가 포함된 데이터베이스의 예를 사용하여 블록의 작동을 고려해 보겠습니다.
약간의 준비 작업을 해보자. 가장 간단한 형태로 요청을 보내고 그 결과를 받을 수 있는 비즈니스 프로세스를 만드는 것이 필요합니다.
또한 이 비즈니스 프로세스에 액세스할 수 있는 엔드포인트를 생성해야 합니다.
초기 단계에서는 이것으로 충분합니다. 애플리케이션을 게시하고 테스트로 넘어갈 수 있습니다. 이를 위해서는 게시 시 자동으로 생성되는 Swagger를 사용하는 것이 매우 편리합니다.
데이터베이스에서 모든 책을 요청해야 하는 간단한 쿼리를 사용합니다.
SELECT * FROM public.book
데이터베이스 편집기에서 생성된 다른 모든 테이블과 마찬가지로 테이블 자체에는 스키마 - 공개를 나타내는 접두사가 있습니다.
요청이 성공적으로 완료되고 결과가 수신된 것을 확인할 수 있습니다.
하지만 문제는 이런 형태로 답을 인지하는 것이 매우 어렵다는 것이다. 가능한 해결책은 요청을 약간 수정하고 필요한 필드(예: 책 제목, 페이지 수)만 남겨 두는 것입니다. 또한 제한을 설정하고 데이터베이스에서 모든 책을 요청하는 것이 아니라 10권으로 제한하는 것이 합리적입니다.
public.book에서 이름, 페이지 선택 LIMIT 10
훨씬 좋아졌지만 여전히 실제 사용에는 적합하지 않습니다. 결국, 비즈니스 프로세스에서는 요청을 받는 것뿐만 아니라 그 결과에 대해 뭔가를 수행해야 합니다. 이를 위해서는 결과를 텍스트 형식으로 갖는 것만으로는 충분하지 않습니다. 나중에 사용하기에 적합한 모델로 바꿔야 합니다.
이를 위해 비즈니스 프로세스로 돌아가서 조금 더 다듬어 보겠습니다. 마지막 블록에는 책 모델 배열인 새 변수를 추가합니다.
요청의 결과로 수신된 JSON을 모델로 변환하는 블록도 필요합니다. 모델로 JSON을 역직렬화합니다.
이전 요청을 반복하여 시각적 인식과 BP에서의 추가 사용 모두에 결과가 훨씬 더 적합해졌는지 확인하겠습니다.
이제 더 복잡한 논리로 넘어갈 수 있습니다. 다음과 같은 비즈니스 프로세스를 만들어 보겠습니다.
- 책 제목을 입력으로 받습니다.
- 어떤 카테고리(장르)에 속하는지 결정합니다.
- 결과적으로 동일한 카테고리의 도서 3권을 무작위로 반환합니다. (이 경우 요청한 도서가 그중에 있어서는 안 됩니다.)
이를 위해 표준 블록을 사용한 검색과 SQL 쿼리 사용을 결합하는 새로운 비즈니스 프로세스를 만들 것입니다.
첫 번째 블록은 제목으로 책을 찾고 해당 책이 속한 카테고리를 결정하는 것입니다. 이를 위해 다음 매개변수와 함께 검색 블록을 사용합니다.
- _With = 카테고리 - 책 자체 외에도 쿼리 결과에는 관련 카테고리 테이블의 정보가 필요합니다.
- _Limit = 1 - 단 한 권의 책만 찾으면 됩니다.
- _Ilike = False - 이름은 요청한 이름과 정확히 일치해야 합니다.
- 이름 - 시작 블록에서 전달된 책 제목의 색인입니다.
인덱스가 0인 Array Element 블록을 사용하여 결과에서 첫 번째(유일한) 책을 가져옵니다.
책은 동시에 여러 다른 카테고리에 속할 수 있으며, 이 경우 그 중 어느 것이든 적합할 것입니다. Random element 블록을 사용하여 무작위로 선택할 수 있습니다.
그 후에는 필요한 모든 데이터가 확보되었으며 남은 것은 요청 자체를 생성하는 것뿐입니다. 이는 다음과 같습니다.
SELECT * FROM public.book WHERE id IN (SELECT rel1_id FROM public.book_categorys_category_books_pivot WHERE book_categorys_category_books_pivot.rel2_id = X) AND id <> Y ORDER BY 무작위() LIMIT 3
여기서 X는 책 카테고리의 ID이고 Y는 책 자체의 ID입니다.
이 쿼리에는 하위 쿼리가 포함되어 있습니다. 먼저 book_categorys_category_books_pivot 테이블(두 테이블 간의 관계에 대한 정보를 저장하는 데 사용됨)에서 선택한 카테고리에 해당하는 모든 도서 식별자를 찾습니다. 그런 다음 원래 비즈니스 프로세스에 제목이 전달된 도서 ID를 제외하고 지정된 범위와 일치하는 임의의 3권의 도서를 찾는 쿼리가 실행됩니다.
프로젝트 데이터베이스 구조에 대한 보다 자세한 연구를 위해 배포 계획 설정에서 DB 열기 버튼을 사용할 수 있습니다.
이를 통해 편집기에서 데이터베이스를 열고 데이터 보기 및 편집에 직접 액세스할 수 있습니다. 그러나 편집기에서 데이터 구조 자체를 변경하면 프로젝트를 더 이상 게시할 수 없다는 사실을 주의하고 고려해야 합니다.
비즈니스 프로세스 생성으로 돌아가 보겠습니다. 요청 컴파일을 완료해야 하며, 이를 위해서는 도서 및 카테고리 ID를 정수에서 문자열로 변환하고 Concat Strings (Multiple) 블록을 사용하여 최종 요청을 조합해야 합니다.
마지막 단계는 쿼리를 실행하고 그 결과를 모델로 변환한 후 쿼리 결과로 End 블록에 보내는 것입니다.
변경 사항을 저장하고, 엔드포인트를 생성하고, 프로젝트를 게시하고, 요청이 올바르게 작동하는지 확인할 수 있습니다. 이 경우 복잡한 복합 쿼리가 포함된 하나의 SQL Exec 블록을 사용하여 다른 많은 블록을 대체하고 비즈니스 프로세스의 구조를 단순화했습니다.
SQL Exec 블록의 사용은 데이터 검색에만 국한되지 않고 다양한 시나리오에서 사용될 수 있습니다. 몇 가지 옵션을 더 자세히 살펴보겠습니다.
- ID=X인 책에 대한 댓글 수 계산
public.comment에서 SELECT COUNT(id) WHERE book_id = X - 댓글에 제공된 모든 평점을 고려하여 책의 평균 평점을 계산합니다.
public.comment에서 AVG(비율) 선택 WHERE book_id = X - 2023년 이전에 작성된 모든 댓글 삭제(예를 들어 로그를 빠르게 지우는 데 사용할 수 있음)
DELETE * FROM public.comment WHERE Created_at < '2023-01-01'
결론적으로 보안을 강화하기 위해 스키마 변경으로 이어질 수 있는 위험한 작업에 대한 필터가 SQL Exec 블록에 추가되었다는 점은 주목할 가치가 있습니다.
애플리케이션이 AppMaster 서버에서 호스팅되는 경우 TABLE|COLUMN|INDEX|CONSTRAINT|SEQUENCE|SCHEMA|DATABASE에 대한 CREATE/ALTER/DROP/TRUNCATE가 필터에 의해 비활성화됩니다. 온프레미스에서 호스팅하는 경우 기본적으로 모든 요청이 제한 없이 제공됩니다.
