ゲスト

マーケティングの教科書 / コース9 — データベースの教科書 / レッスン 9-3

コース9 — データベースの教科書

マーケターのためのデータベース使い分け地図

所要時間: 8分  |  更新: 2026-06-11

コース9の最終レッスンです。9-1(MySQL vs MariaDB)と 9-2(BigQuery vs MySQL)で個別の比較をしましたが、ここでは一歩引いて「データを扱う基盤の全体地図」を描き、マーケターがどこまで学ぶべきかを整理します。

データ基盤の3つの役割

私はマーケターに説明するとき、データベースの世界を3つの役割に分けます。

役割 代表製品 得意なこと マーケでの接点
RDB(業務システムの台帳) MySQL、MariaDB、PostgreSQL 注文・会員などの正確な記録と更新(OLTP) EC の注文データ、会員マスタ
DWH(分析の倉庫) BigQuery、Snowflake、Redshift 大量データの集計・横断分析(OLAP) GA4 データ、広告データの統合分析
NoSQL(柔軟な保管庫) Redis、MongoDB、DynamoDB 高速キャッシュ、形が決まらないデータ セッション管理、レコメンドの裏側

ポイントは、これらが競合ではなく分業だということです。注文は RDB に記録され、夜間や準リアルタイムで DWH にコピーされ、分析は DWH で行う — これが現代の標準的なデータの流れです。

マーケターに一番関係が深いのは DWH

日々の意思決定(どの広告に予算を寄せるか、どのセグメントが LTV が高いか)に必要なのは、複数のデータソースを横断した集計です。

  • GA4 の行動データ
  • 広告媒体(Google/Meta)の出稿データ
  • 基幹システムの売上・顧客データ

これらは別々の場所にあるので、DWH に集めて初めて「広告 A 経由の顧客の 6 ヶ月 LTV」のような問いに答えられます。GA4 には BigQuery への無料エクスポート機能があり(標準プロパティでも利用可)、これが「マーケターが BigQuery に触る」最初の入口になることが多いです。

SQL はマーケターの武器になるか

私の答えは「SELECT 文だけでも学ぶ価値がある」です。理由は3つあります。

  1. 依頼の質が上がる — データチームに「何ができるか」を理解した依頼が出せる
  2. 探索が自分で完結する — ダッシュボードにない切り口を自分で見られる
  3. 要件定義に強くなる — 計測設計(コース6-2)の段階で、後の分析を見据えた設計ができる

逆に、INSERT/UPDATE などの更新系や、DB 設計・チューニングはエンジニアの領域です。マーケターは「読む SQL」に集中すれば十分です。

使い分け地図の実例

小さな EC 事業を例にすると、こうなります。

  1. 注文・会員データ → MySQL(アプリの台帳)
  2. サイト行動データ → GA4 → BigQuery エクスポート
  3. 広告データ → 各媒体 → コネクタで BigQuery
  4. BigQuery 上で顧客 ID をキーに結合 → LTV・CPA 分析(コース5-5、6-4)
  5. 結果を Looker Studio などの BI ツールで可視化

この流れの中で、マーケターが自分で触るのは 4 と 5 です。

まとめ

  • RDB は台帳、DWH は分析倉庫、NoSQL は柔軟な保管庫。競合ではなく分業
  • マーケの意思決定に効くのは DWH。GA4 → BigQuery エクスポートが入口
  • マーケターは「読む SQL」(SELECT)だけで十分に武器になる

参考

さらに深く読む