Zenn
🫧

Bubble→MySQLへの設計移行メモ

に公開
MySQL
bubble
ノーコード
ローコード
移行
tech

概要

  • BubbleのOption sets / App dataをMySQLへ移行するときのテーブル設計メモ
  • サンプルとして「カテゴリごとにメール通知可否を判定し、ユーザーは複数カテゴリを持つ」という仕様をMySQLの定義で再現する

サンプルシナリオ

  • Bubble → MySQLへ移行
  • Bubble側の既存仕様: 特定のカテゴリに属するユーザーにはメール通知を行う

移行元：Bubble側のデータ構造

種別 例 特徴
Option sets 性別 / タグ / カテゴリ 動的に追加されないマスタデータ
App data ユーザー / 問い合わせ 動的に追加されるデータ。Option sets参照可

Option sets：Category

  • カテゴリAかカテゴリBを持つユーザーに対してメール送付を行う仕様
  • なので、Option setsの機能であるattibutesを使ってis_notifiableという自作のプロパティを付与
    • is_notifiableが1なら、Bubble側でメール送信を行うようにしている
表示名 is_notifiable
カテゴリA 1
カテゴリB 1
カテゴリC 0
カテゴリD 0
カテゴリE 0

App data：User

  • 1人のユーザーに対して複数のCategoryを設定できる設計にしている
  • Unique IDはBubble側で自動的に採番されるユニークID
カラム 型例
email email
name string
category List of Category (1対多)
Unique ID Bubble 自動採番

移行先：MySQL側のテーブル設計

  • 多対多なので users / categories / user_categories の 3 テーブル構成

categories

  • カテゴリテーブル
  • Option setsのCategoryと対応
column type key/制約 note
id BIGINT UNSIGNED PK, AUTO_INCREMENT
name VARCHAR(255) UNIQUE, NOT NULL 表示名
is_notifiable TINYINT(1) NOT NULL, DEFAULT 0 1 = メール対象
created_at TIMESTAMP
updated_at TIMESTAMP

users

  • ユーザーテーブル
  • App dataのUserと対応
  • BubbleのApp dataにあるUserには自動採番されたUnique IDがあるので、移行時にも値を保持して整合性を担保しておく
column type key/制約 note
id BIGINT UNSIGNED PK, AUTO_INCREMENT
bubble_unique_id CHAR(36) UNIQUE, NULL Bubble の UID
email VARCHAR(255) UNIQUE, NOT NULL
name VARCHAR(255) NOT NULL
created_at TIMESTAMP
updated_at TIMESTAMP

user_categories

  • App dataにあるUserのList of Categoryに対応するための中間テーブル
  • user_idと category_idでプライマリキーを設定
column type key/制約 note
user_id BIGINT UNSIGNED FK → users.id
category_id BIGINT UNSIGNED FK → categories.id

まとめ

  • とりあえずOption setsとApp dataの両方をテーブルに置き換えればOK

Discussion