Console/ Marketing/ DB Structure & Core Data Model Blueprint

DB Structure & Core Data Model Blueprint

Core entities · relational schema groups · mode-aware content model · event domain · rewards domain · tracking domain
marketing Live Batch MKT-07 · Document 7 Author: ChatGPT
Claude-added · Metadata
Primary author
ChatGPT (verbatim source)
Publisher
Claude (ingest · format · index · publish)
Category
marketing
Group
marketing
Status
live
List position
Marketing #7 (freshly-added · list extends from 6 → 7 contiguous)
Route
/marketing/db-structure-core-data-model-blueprint.html
Related docs
Marketing #4 · MICE 84-Service Master Catalog · Marketing #5 · Together Mode Architecture V2 · Marketing #6 · Prototype Design Readiness & System Blueprint
Claude did
added TOC anchors (20 main sections + 60+ sub-sections) · rendered all field lists as compact 2-col grid for readability · added metadata block · added cross-links · added appendix · added glossary
Claude did NOT
rewrite · summarise · shorten · remove words · change wording of the primary source
Batch
MKT-07
Claude-added · Index

สารบัญ · anchor links สำหรับ 20 sections หลัก + sub-sections ของ ChatGPT primary source.

DB Structure & Core Data Model Blueprint

เอกสารฉบับนี้เป็นพิมพ์เขียวเชิงโครงสร้างข้อมูลสำหรับ Together Super App V2 โดยมีจุดประสงค์เพื่อทำให้สิ่งที่ถูกออกแบบไว้ใน prototype, screen logic, Together Mode, content architecture และระบบงานเชิงธุรกิจ สามารถเชื่อมกันบนฐานข้อมูลและ model กลางชุดเดียวได้อย่างเป็นระบบ

เอกสารนี้ไม่ใช่เพียงรายการตารางฐานข้อมูล แต่เป็น “แบบจำลองแกนกลางของแพลตฟอร์ม” ที่ใช้ร่วมกันระหว่าง:

แกนคิดสำคัญคือการทำให้ทุกหน้าจอ ทุก block ทุก flow ทุก content item และทุก service สามารถอ้างอิงกลับมายัง object model ชุดเดียวกันได้
เพื่อให้แพลตฟอร์มไม่กระจายเป็นงานเฉพาะหน้า แต่เติบโตเป็นระบบที่ประกอบ ขยาย เชื่อม และวัดผลได้จริง

1. หลักคิดของ Core Data Model

Core Data Model ของ Together Super App V2 ต้องตอบโจทย์พร้อมกัน 4 ชั้น คือ:

  1. Platform Structure Layer
    ใช้เก็บโครงของแพลตฟอร์ม เช่น mode, screen, block, journey, service
  2. Business Domain Layer
    ใช้เก็บ domain จริงของธุรกิจ เช่น event, venue, hotel, merchant, reward, campaign, user, operator
  3. Content & Presentation Layer
    ใช้เก็บ content item, localization, media asset, content-to-block mapping, UI-config-driven slots
  4. Tracking & Intelligence Layer
    ใช้เก็บพฤติกรรม, event logs, funnel, conversion signals, recommendation input, KPI outputs

ถ้าไม่มีการแยก 4 ชั้นนี้ชัด ระบบจะเริ่มปะปนกัน เช่น:

ดังนั้นโครงฐานข้อมูลควรออกแบบให้ “รองรับการเปลี่ยนแปลง” ไม่ใช่แค่ “เก็บข้อมูลได้”

2. หลักการออกแบบฐานข้อมูลของ Together Super App V2

2.1 Mode-aware

ทุก object ที่เกี่ยวกับการแสดงผลควรมีความสัมพันธ์กับ mode ได้
อย่างน้อยในระดับ:

โหมดหลักที่ยืนยันใช้คือ:

2.2 Screen-to-Block-to-Content

หน้าจอไม่ควรผูก content แบบ hardcoded ทั้งหมด
แต่ควรมีชั้น mapping:

screen → block → content mapping → content item

2.3 Configurable before custom code

สิ่งที่ลูกค้าเปลี่ยนบ่อย เช่น:

ควรอยู่ใน config/data model ก่อนเสมอ

2.4 Domain-first, UI-aware

ฐานข้อมูลควรเริ่มจาก domain model จริงก่อน
แต่ต้องออกแบบให้รองรับการ render บน UI ได้ดี
ไม่ใช่เก็บแบบ normalized จน UI ใช้ยากเกินไป
และไม่ใช่ denormalized จน maintain ยาก

2.5 Tracking-ready by design

ต้องมี key และ structure ที่พร้อมรองรับ tracking ตั้งแต่ต้น
เช่น:

3. Core Entity Families

Core entities ของแพลตฟอร์มควรถูกแบ่งเป็น 10 families

  1. Platform Structure
  2. Experience & Navigation
  3. Content & Media
  4. Identity & Access
  5. MICE Domain
  6. Trip / Stay / Shopping Domain
  7. Rewards & Campaign Domain
  8. Services & Support Domain
  9. Commerce & Transaction Domain
  10. Tracking & Intelligence Domain

4. Platform Structure Tables

4.1 modes

เก็บรายการ Together Modes

ฟิลด์แนะนำ:

ตัวอย่าง mode_code:

4.2 screens

เก็บรายการหน้าจอทั้งหมด

ฟิลด์แนะนำ:

4.3 screen_modes

mapping ว่าหน้าจอใดใช้กับ mode ใด
เพราะบางหน้าจออาจ:

ฟิลด์:

4.4 blocks

เก็บรายการ block / component หลักในแต่ละหน้าจอ

ฟิลด์:

4.5 journeys

เก็บ flow หลักของผู้ใช้

ฟิลด์:

4.6 journey_steps

เก็บลำดับ step ของแต่ละ journey

ฟิลด์:

4.7 services

เก็บรายการบริการใน platform

ฟิลด์:

4.8 service_categories

เก็บหมวดบริการ

ฟิลด์:

5. Content & Media Tables

5.1 content_items

เก็บ content กลางทุกชนิด

ฟิลด์:

5.2 content_localizations

ใช้รองรับหลายภาษาแบบขยายได้

ฟิลด์:

5.3 media_assets

เก็บไฟล์ภาพ วิดีโอ เอกสาร ไอคอน ฯลฯ

ฟิลด์:

5.4 content_media_mapping

mapping content กับ media

ฟิลด์:

5.5 content_block_mapping

mapping ว่า content ไหนขึ้น block ไหน

ฟิลด์:

5.6 tags

เก็บ tag กลาง

ฟิลด์:

5.7 content_tags

mapping content กับ tag

ฟิลด์:

6. Identity & Access Tables

6.1 users

เก็บผู้ใช้

ฟิลด์:

6.2 roles

เก็บ role

ฟิลด์:

ตัวอย่าง:

6.3 permissions

เก็บ permission รายการ

ฟิลด์:

6.4 role_permissions

mapping role กับ permission

ฟิลด์:

6.5 user_roles

mapping user กับ role

ฟิลด์:

6.6 tenants

รองรับ multi-tenant

ฟิลด์:

6.7 tenant_settings

เก็บ setting ของแต่ละ tenant

ฟิลด์:

7. MICE Domain Tables

7.1 events

เก็บงานอีเวนต์หลัก

ฟิลด์:

7.2 event_days

เก็บวันของงาน

ฟิลด์:

7.3 sessions

เก็บ session ใน agenda

ฟิลด์:

7.4 speakers

เก็บวิทยากร

ฟิลด์:

7.5 session_speakers

mapping session กับ speaker

ฟิลด์:

7.6 exhibitors

เก็บ exhibitor

ฟิลด์:

7.7 sponsors

เก็บ sponsor

ฟิลด์:

7.8 venues

เก็บ venue หลัก

ฟิลด์:

7.9 venue_zones

เก็บ hall / room / zone

ฟิลด์:

7.10 registrations

เก็บข้อมูลลงทะเบียนเข้างาน

ฟิลด์:

7.11 checkins

เก็บ check-in จริง

ฟิลด์:

8. Trip / Stay / Shopping Domain Tables

8.1 places

เก็บสถานที่ท่องเที่ยว จุดสนใจ ร้าน หรือ landmark

ฟิลด์:

8.2 routes

เก็บ route หรือ itinerary template

ฟิลด์:

8.3 route_stops

จุดแวะของ route

ฟิลด์:

8.4 itineraries

แผนเที่ยวของผู้ใช้

ฟิลด์:

8.5 itinerary_items

รายการในแผนเที่ยว

ฟิลด์:

8.6 hotels

เก็บข้อมูลที่พัก

ฟิลด์:

8.7 hotel_offers

เก็บโปรโมชันหรือข้อเสนอห้องพัก

ฟิลด์:

8.8 merchants

เก็บร้านค้า/ผู้ประกอบการ

ฟิลด์:

8.9 products

เก็บสินค้า

ฟิลด์:

8.10 offers

เก็บ offer กลาง

ฟิลด์:

9. Rewards & Campaign Domain Tables

9.1 wallets

เก็บกระเป๋า point/reward ของผู้ใช้

ฟิลด์:

9.2 wallet_transactions

เก็บธุรกรรมแต้ม

ฟิลด์:

9.3 campaigns

เก็บ campaign

ฟิลด์:

9.4 missions

เก็บภารกิจ

ฟิลด์:

9.5 user_missions

เก็บความคืบหน้าภารกิจของผู้ใช้

ฟิลด์:

9.6 vouchers

เก็บ voucher

ฟิลด์:

9.7 redemptions

เก็บการแลกสิทธิ์

ฟิลด์:

10. Services & Support Domain Tables

10.1 support_cases

เก็บเคส support

ฟิลด์:

10.2 service_requests

เก็บคำร้อง service อื่น ๆ

ฟิลด์:

10.3 esim_packages

เก็บ package eSIM

ฟิลด์:

10.4 insurance_plans

เก็บแผนประกัน

ฟิลด์:

10.5 transport_nodes

เก็บ node ด้าน transport

ฟิลด์:

11. Commerce & Transaction Tables

11.1 orders

เก็บคำสั่งซื้อ

ฟิลด์:

11.2 order_items

เก็บรายการสินค้าใน order

ฟิลด์:

11.3 payments

เก็บการชำระเงิน

ฟิลด์:

11.4 sponsorship_packages

เก็บ package sponsor/exhibitor

ฟิลด์:

12. Tracking & Intelligence Tables

12.1 tracking_sessions

เก็บ session การใช้งาน

ฟิลด์:

12.2 tracking_events

เก็บ event พฤติกรรม

ฟิลด์:

ตัวอย่าง event_name:

12.3 screen_views

ถ้าต้องการ table สรุปแยก

ฟิลด์:

12.4 searches

เก็บคำค้นหา

ฟิลด์:

12.5 conversions

เก็บ conversion สำคัญ

ฟิลด์:

13. Relationship Blueprint ระดับภาพรวม

ความสัมพันธ์ระดับแกนควรเป็นดังนี้:

14. Mapping Between DB and Prototype / Design Management

14.1 Screen Registry → screens

screen registry ใน design management ควร map ตรงกับตาราง screens

14.2 Block Registry → blocks

block registry ควร map ตรงกับตาราง blocks

14.3 Journey Registry → journeys + journey_steps

journey registry ควร map ลง 2 ตารางนี้โดยตรง

14.4 Content Mapping → content_items + content_block_mapping

สิ่งที่ออกแบบใน prototype ว่ากล่องไหนขึ้น content อะไร ต้อง map ลง 2 ตารางนี้

14.5 Service Catalog → services + service_categories

เอกสาร MICE 84-Service Master Catalog ควรถูก map ลง services และ service_categories ได้ในอนาคต

14.6 Tracking Framework → tracking_events

event taxonomy ที่กำหนดใน tracking framework ต้อง map ลง tracking_events ได้ตรง

15. Mapping กับ Together Mode Architecture

เอกสาร Together Mode Architecture for Super App V2 ต้อง map เข้าฐานข้อมูลอย่างน้อยดังนี้

Trip Mode

เชื่อมกับ:

MICE Mode

เชื่อมกับ:

Rewards Mode

เชื่อมกับ:

Shopping Mode

เชื่อมกับ:

Services Mode

เชื่อมกับ:

Stay Mode

เชื่อมกับ:

16. ข้อเสนอเรื่อง Normalization / Denormalization

ควร normalized ในชั้น core

เช่น:

ควรมี denormalized view / cache layer สำหรับ UI

เช่น:

เหตุผลคือ:

ดังนั้นควรแยก:

17. สิ่งที่ควรเตรียมสำหรับ API Layer

ทุก entity สำคัญควรรองรับ:

ตัวอย่าง API family:

18. สิ่งที่ควรเผื่อไว้สำหรับ Enterprise

Enterprise tier ต้องการมากกว่าการมีตารางเพิ่ม
แต่ต้องการ schema ที่รองรับ:

ดังนั้น field ที่ควรเผื่อไว้ในหลายตารางคือ:

19. ตัวอย่างกลุ่ม schema สำหรับเริ่มต้นจริง

Phase 1 — Foundation Schema

Phase 2 — MICE + Trip + Rewards Core

Phase 3 — Stay + Shopping + Services + Commerce

Phase 4 — Enterprise & Intelligence

20. สรุปเชิงยุทธศาสตร์

DB Structure & Core Data Model Blueprint ฉบับนี้มีบทบาทสำคัญมาก เพราะเป็นจุดที่ทำให้:

เอกสารฉบับนี้ควรถูกใช้ร่วมกับ:

  1. MICE 84-Service Master Catalog
  2. Together Mode Architecture for Super App V2
  3. Prototype Design Readiness & System Blueprint

เมื่อใช้ร่วมกันครบ จะได้ชุดเอกสารที่เชื่อมกันดังนี้:

ท้ายที่สุด เอกสารฉบับนี้คือสะพานระหว่าง “ภาพของระบบ” กับ “โครงของระบบ”
และเป็นฐานที่ทำให้ Together Super App V2 สามารถขยับจาก design-led prototype ไปสู่ platform ที่ build ได้จริง, integrate ได้จริง, และ scale ได้จริง

Claude-added · Cross-links + Appendix

ส่วนนี้ ไม่ใช่ ข้อความของ ChatGPT · Claude เพิ่มเพื่อเชื่อมเอกสารเข้าระบบ marketing library · สามารถลบได้โดยไม่กระทบเนื้อหาหลัก.

ตำแหน่งของเอกสารนี้ใน Marketing track:

เอกสารนี้เชื่อมกับ Marketing #4/#5/#6 อย่างไร (ตามที่ §14 + §15 + §20 ของ primary source ระบุ):

สรุปความสัมพันธ์ระหว่าง 4 เอกสารแกน (§20 primary source):

Snapshot สถิติ (Claude นับจาก primary source · ไม่ใช่ข้อความ ChatGPT):

Forward hooks (งานถัดไปที่ schema นี้เตรียมทางไว้ให้):

Publisher note: Claude มีบทบาทเป็น ingester + formatter + indexer เท่านั้น · ไม่แก้ wording ของ ChatGPT primary source · ทำเฉพาะ: HTML conversion (markdown → HTML list + heading), anchor IDs (20 main sections + 60+ sub-sections), TOC, metadata block, field lists rendered เป็น compact 2-col grid เพื่อ readability (เก็บคำและลำดับต้นฉบับครบ), cross-links/appendix นี้, และ glossary ด้านล่าง · ข้อความต้นฉบับ preamble + §1–§20 ทุกตัวอักษรอยู่ครบไม่มีการลบหรือสรุป · ตารางและรายการฟิลด์ทุกตัวถูกยกมาจาก primary source ตรง ๆ.

Claude-added · Glossary (optional)

คำศัพท์ที่ปรากฏบ่อยในเอกสารนี้ · สรุปให้ผู้อ่านไม่ใช่ technical stakeholder · ไม่ใช่ ข้อความต้นฉบับของ ChatGPT.

Mode-aware
คุณสมบัติของ schema ที่ให้ทุก object แสดงผลได้แตกต่างตาม Together Mode ที่ user เลือก · มี 4 visibility levels: directly bound / optionally visible / recommended in mode / hidden in mode · implement ผ่าน screen_modes + content_block_mapping.mode_id — §2.1.
Content mapping
ชั้น data layer ที่ผูก content entity เข้ากับ block บนหน้าจอ · ไม่ hardcode ใน UI code · เปลี่ยนได้ runtime · ตาราง content_block_mapping เป็น source — §2.2, §5.5, §14.4.
Source-of-truth tables
ตารางที่เก็บข้อมูลต้นฉบับ normalized อย่างเคร่งครัด · เป็น authoritative record · ใช้สำหรับ write operations · เช่น users · events · hotels · products — §16.
Serving / read model
ตารางหรือ cached view ที่เก็บข้อมูล denormalized ไว้ serve UI ได้เร็ว · ไม่ใช่ authoritative · rebuild จาก source-of-truth ได้ · เช่น home mode feed / event home summary / hotel card aggregate — §16.
Tenant
ขอบเขตลูกค้า/แบรนด์/หน่วยงานที่ได้รับ deployment แยก · isolate identity + content + branding + role policy · ตาราง tenants + tenant_settings + field tenant_id ในหลายตาราง — §6.6, §18.
external_ref
ฟิลด์ reserved สำหรับเก็บ ID จากระบบภายนอก · รองรับ integration + data migration + sync back · เป็นส่วนหนึ่งของ Enterprise-ready fields — §18.
Conversion
event สำคัญทาง business ที่แสดงว่า user ทำสิ่งที่ platform ต้องการ · เช่น registration_completed · reward_redeemed · order completed · stored แยกจาก generic tracking_events เพื่อ funnel analysis — §12.5.
Denormalized view
ตารางหรือ materialized view ที่ aggregate + join ล่วงหน้าเพื่อลด query cost ตอน render · update ผ่าน batch job / cache refresh · ไม่เขียนตรง · อ่านอย่างเดียวจาก UI — §16.
4-Layer Data Model
Platform Structure + Business Domain + Content & Presentation + Tracking & Intelligence · แยกเพื่อไม่ปนกัน · §1 ของ primary source.
10 Entity Families
ชุดใหญ่ของตาราง 10 กลุ่ม · §3 · map 1-1 กับ §4–§12 section schemas.
Phase rollout (1-4)
ลำดับ implement schema · Phase 1 Foundation (mode/screen/block/user/content/tracking base) → Phase 2 MICE+Trip+Rewards core → Phase 3 Stay+Shopping+Services+Commerce → Phase 4 Enterprise+Intelligence — §19.
mode_fit_json
ฟิลด์ใน routes ที่ระบุว่า route นี้เข้ากับ mode ไหนบ้าง · เก็บเป็น JSON เพราะ 1 route อาจเหมาะกับหลาย mode พร้อม weight ต่างกัน — §8.2.
← Marketing library · #1 · #2 · #3 · #4 · #5 · #6 · Main Console