버블 데이터베이스 트리거: 데이터 관리 자동화 및 최적화

버블(Bubble.io)의 데이터베이스 트리거는 앱에서 데이터가 변경될 때마다 자동으로 실행되는 강력한 자동화 도구입니다. 이러한 트리거는 알림 전송, 관련 데이터 업데이트, 외부 서비스와의 통합 등 다양한 작업을 자동화하여 앱을 더 효율적이고 빠르게 유지할 수 있게 도와줍니다.

이 글에서는 버블의 데이터베이스 트리거를 설정하고 활용하여 앱 기능을 개선하는 방법을 살펴보겠습니다.

데이터베이스 트리거란?

버블의 데이터베이스 트리거 기능은 백엔드 워크플로우(Backend Workflow) 내에서 사용할 수 있습니다.

특정 데이터가 추가, 수정, 삭제될 때마다 사용자가 정의한 조건에 따라 자동으로 실행됩니다.

데이터베이스 트리거의 기본 개념

1. 변경 전 데이터(Thing before change)와 변경 후 데이터(Thing now)

• 변경 전 데이터: 데이터가 변경되기 이전의 상태를 반환합니다. 예를 들어 사용자가 이름을 "Peter"에서 "Park"로 변경했다면, 변경 전 데이터는 "Peter"입니다.
• 변경 후 데이터: 데이터가 변경된 이후의 상태를 반환합니다. 위 예시에서 변경 후 데이터는 "Park"가 됩니다.

2. 트리거 이벤트 생성하기

"Backend Workflow" 탭으로 이동하여 새 백엔드 워크플로우를 추가한 후, "New database trigger event"를 선택합니다.

다음의 세 가지 필드를 입력해야 합니다.

• Event name: 식별을 위한 설명적인 이름입니다.
• Type: 이벤트가 감지할 데이터 타입을 설정합니다.
• Only when: 이 필드를 비워두면 데이터가 변경될 때마다 트리거가 실행되어 불필요한 작업을 만들 수 있습니다. 따라서 성능 최적화를 위해 변경 전 데이터와 변경 후 데이터를 기준으로 조건을 설정하는 것이 좋습니다.

예를 들어, 새로운 요리(Dish)가 생성될 때 트리거를 설정하려면 이와 같이 작성할 수 있습니다.

• Event name: Dish create
• Type: Dish
• Only when: Dish before change is empty and Dish now is not empty

3. 'Only when' 조건을 다양한 경우에 활용하기

• 생성 시: "Thing before change is empty"를 조건으로 설정합니다.
• 삭제 시: "Thing now is empty"를 조건으로 설정합니다.
• 생성 또는 업데이트 시: "Thing now is not empty"를 조건으로 설정합니다.

데이터베이스 트리거 사용 시 유의사항

1. 워크플로우 내에서 여러 번 변경이 이루어질 때

워크플로우가 한 항목을 여러 번 업데이트하더라도 트리거는 한 번만 실행됩니다.

• Thing before change는 첫 변경 전 데이터를 나타냅니다.
• Thing now는 최종 변경 후 데이터를 나타냅니다.

2. 프라이버시 규칙

• 트리거 이벤트 내 액션에서 현재 사용자(Current User)를 참조할 수 있습니다.
• 데이터베이스 트리거는 모든 데이터를 접근할 수 있는 관리 권한으로 실행되므로, 프라이버시 규칙이 적용되지 않습니다.

3. 트리거는 다른 트리거를 실행시키지 않습니다.

트리거가 데이터를 변경하더라도 다른 트리거가 연쇄적으로 실행되지는 않습니다.

4. 조건 설정 시 데이터 소스

트리거 조건(Only when)에는 Thing now와 Thing before change만 사용 가능합니다.

액션에서는 Thing now, Thing before change, Current user, 데이터 검색(Do a search for…) 등을 모두 활용할 수 있습니다.

5. 워크로드 소모

• 트리거 워크플로우도 일반 워크플로우처럼 서버 용량을 소모합니다. 데이터를 수정할 때마다 여러 트리거가 실행되면 자원 사용량이 크게 증가할 수 있으므로, 정확한 조건을 설정하여 필요한 경우에만 트리거가 실행되도록 해야 합니다.
• 동시에 20개 이상의 트리거가 실행될 경우, 초과된 트리거는 순차적으로 예약되어 과부하를 방지합니다.

실제 활용 사례

사례 1: 요리 이름으로 레스토랑 검색 기능 구현하기

사용자가 특정 요리 이름으로 레스토랑을 검색할 수 있도록 설정합니다.

우선, Restaurant와 Dish 두 가지 데이터 타입을 생성합니다. Restaurant 타입에는 해당 레스토랑의 모든 요리 이름을 모아두는 Search_Metadata 필드를 만듭니다.

레스토랑 데이터 타입에는 요리 목록을 저장하는 Dishes 필드를 추가하고, 새 요리가 추가될 때마다 워크플로우를 통해 이 필드를 업데이트합니다.

데이터베이스 트리거를 설정해, 요리(Dish)가 생성되거나 수정될 때 연결된 레스토랑(Restaurant)의 Search_Metadata 필드를 자동으로 업데이트하도록 합니다. 이렇게 하면 요리 이름만으로도 레스토랑을 빠르게 찾을 수 있습니다.

추가 팁: Search_Metadata 필드에는 요리 이름 외에도 사용자들이 자주 검색하는 다른 속성(예: 식재료, 요리 특징 등)도 함께 저장하면 더욱 효과적입니다.

사례 2: 레스토랑 좋아요 기능 구현하기

사용자가 레스토랑에 좋아요를 누를 수 있는 기능을 만듭니다.

Restaurant 타입과 Restaurant_Like 타입 두 가지가 필요합니다. Restaurant 타입에는 좋아요 수를 기록하는 Like_Count 필드를 만듭니다. Restaurant_Like 타입은 특정 사용자가 특정 레스토랑에 좋아요를 눌렀는지 여부를 관리하는 용도로 쓰며, 이 타입에는 관련된 레스토랑을 참조하는 Restaurant 필드를 포함합니다.

• ‘좋아요’ 추가 트리거

트리거 조건을 "Restaurant_Like before change is empty"로 설정해, 새로운 좋아요가 생성된 경우에만 실행되도록 합니다. 트리거가 실행되면 해당 레스토랑(Restaurant_Like now로 참조)의 Like_Count가 자동으로 1 증가합니다.

• ‘좋아요’ 취소 트리거

트리거 조건을 "Restaurant_Like now is empty"로 설정해, 좋아요가 삭제된 경우에만 실행됩니다. 트리거가 실행되면 이전에 연결된 레스토랑(Restaurant_Like before change로 참조)의 Like_Count를 자동으로 1 감소시킵니다.

추가 팁: 관련된 레스토랑을 참조할 때는 항상 Restaurant_Like now 또는 Restaurant_Like before change에 데이터가 있는지 미리 확인하는 것이 좋습니다.

이렇게 데이터베이스 트리거를 잘 활용하면 앱의 성능과 사용자 경험을 모두 향상시킬 수 있습니다.

📌 버블 외주 개발 맡기기 전, 3가지만 꼭 확인하세요!

✅ 버블 공식 에이전시인지 확인하세요.

리트머스는 전 세계 337곳 중 12위,

동아시아권에서는 1위입니다 🏆 (25.04.08 기준, 현재 공식 순위 보기)

✅ 버블 공식 자격증이 있는지 체크하세요.

리트머스는 전 세계 약 600명뿐인 버블 공식 자격증 보유자 중

6명의 전문가가 함께합니다 🎖️ (글로벌 TOP 10 규모!)

✅ 유사한 프로젝트 경험이 있는지 꼭 살펴보세요.

리트머스는 SaaS, ERP, AI, 마켓플레이스 등

다양한 웹과 앱을 성공적으로 구축한 경험이 있습니다 💻 (포트폴리오 보기)

버블 개발은 "할 수 있다"보다 "제대로 하는 게" 더 중요합니다.

리트머스가 실력과 경험으로 완성도 높은 결과를 약속드립니다!

언제든지 무료 문의 해보세요 ☺️

문의하러 가기 🚀