🎯 New Schema Design (Phase 2) — S1, S2, S3, S8 & S9¶

ออกแบบ schema เป้าหมาย (target design) เพื่อรองรับ requirement ที่ปรับปรุงจากระบบเดิม โดยอ้างอิงจาก SRS โดยตรง — S1 (RLPD-Dev-P2_SRS-S1_LCS v3.0.0, TOR 7.11 · พัฒนาใหม่ greenfield), S2 (RLPD-Dev-P2_SRS-S2_PJOS v2.0.0, TOR 7.12 · พัฒนาใหม่ greenfield), S3 (RLPD-Dev-P2_SRS-S3_PRC v2.0.0, TOR 7.13 · พัฒนาใหม่ greenfield), S8 (RLPD-Dev-P2_SRS-S8_Official Website v2.0.0, TOR 7.18) และ S9 (RLPD-Dev-P2_SRS-S9_WPT v1.0.0, TOR 7.19)

TARGET DESIGN — ไม่ใช่สถานะปัจจุบัน (not current state)

เอกสารชุดนี้คือ schema ที่ออกแบบใหม่ เพื่อ implement requirement — ยังไม่ได้สร้างใน DB จริง · สถานะปัจจุบันของ DB อยู่ที่ docs/database/ (S8 = legacy RLPD_WEB .226, S9 = PORTAL .149) · ทุก DDL ในที่นี้เป็น proposal สำหรับทีมพัฒนา — ต้องผ่าน review + migration plan ก่อนใช้งาน

หลักการออกแบบ (Design Decisions)¶

#	Decision	เหตุผล
D1	เป้าหมายคือ Single DB `PSDBPRDDB` ทั้ง S8 และ S9	สอดคล้องนโยบาย Phase 2 (รวมเข้าฐานข้อมูลกลางเชิงเดี่ยว) — S8 ปัจจุบันยังเป็น legacy แยกเครื่อง
D2	แยก schema namespace ต่อระบบ — `WEB` (S8), `PORTAL` (S9)	กันชนกันในฐานข้อมูลเดียว, ตรงกับ S9 ที่ใช้ `PORTAL` อยู่แล้ว
D3	S8 = redesign ใหม่ทั้งชุด (ไม่ยกตาราง legacy มาตรง ๆ)	legacy มีตารางขยะ/ซ้ำ (`Content_copy1/2/3`, `Content++`, `_bk`, `_tmp`) และ 0 FK · ออกแบบใหม่ให้ normalize + มี FK + audit/workflow มาตรฐาน
D4	S9 = ขยายต่อ (extension) จาก `PORTAL` เดิม	schema เดิมดี (มี `UserProfile`/`Pid`, `RLPDSystems`, `PermissionRequest`, `ApiTokens`/Query Builder, routing ผ่าน `PetitionRequestDepartments`) — เพิ่มเฉพาะส่วนที่ SRS ต้องการ ทุกตาราง tag reuse / modify / new
D5	NVARCHAR ทุก text ภาษาไทย, `datetime`/`datetime2`, T-SQL (MSSQL)	ตรง stack กรมฯ (MSSQL)
D6	Audit columns มาตรฐาน: `CreatedAt/CreatedBy/UpdatedAt/UpdatedBy` + `IsActive`/`IsDeleted` (soft delete)	ตามแบบที่ทั้งสอง schema ใช้อยู่
D7	PK: S8 ใช้ `uniqueidentifier` (ให้ GUID legacy carry over ตอน migrate); S9 ตามของเดิม (`nvarchar` code / `int identity` / `uniqueidentifier`) ให้ join กับตารางเดิมได้	migration-friendly
D8	Auth + Authorization รวมศูนย์ทุกระบบ: authn = Keycloak SSO (ThaiD/AD, realm `rlpd`); authz = กำหนดสิทธิ์ที่เดียวที่ S9 Portal (`PORTAL.ModuleRoles` + `PORTAL.UserRole`) → sync เป็น Keycloak client roles → ทุกระบบ (รวม S8) อ่าน role จาก JWT ไม่เก็บ user-role เอง	REQ-WPT-005 "Roles & Permissions รวมศูนย์"; S8 จึงไม่มีตาราง `Role`/`UserRole`

ข้อสังเกตจาก SRS (ต้อง align กับลูกค้า)

SRS S8 ระบุใน Tech Stack/Architecture ว่า "Schema เดิม + Schema เพิ่มเติมสำหรับ Web API" (คือเก็บของเดิมแล้วต่อเติม) แต่ Exec Summary มุ่ง บูรณาการเข้า Single DB และผู้ใช้สั่งให้ "design new schema" → เอกสารนี้เลือกแนวทาง redesign สะอาดบน Single DB พร้อม migration mapping จาก legacy ในแต่ละตาราง · ถ้าลูกค้ายืนยันให้คงตาราง legacy เดิมจริง ๆ ให้ใช้เอกสารนี้เป็น to-be แล้วทำ adapter view แทน

S3 (PRC) — ข้อต่างจาก decisions ข้างต้น

S3 เป็น greenfield (ไม่มี DB/GUID เดิม) จึงเลือก PK = int IDENTITY แทน uniqueidentifier (ต่างจาก D7) และ CreatedBy/UpdatedBy เป็น int FK → PRC.AppUser (ต่างจาก S8/S9 ที่เก็บเป็น nvarchar) — รายละเอียดใน s3_activity_report/changes.md

ระบบในชุดนี้¶

System	Schema	ฐานข้อมูลปัจจุบัน → เป้าหมาย	TOR	ไฟล์
S1 — Legal Consultation (LCS)	`LCS`	(ใหม่ greenfield) → `PSDBPRDDB`	7.11	schema.sql · data_dict · ERD · impl (changes ยุบใน index)
S2 — Proactive Justice (PJOS)	`PJOS`	(ใหม่ greenfield) → `PSDBPRDDB`	7.12	schema.sql · data_dict · ERD · impl (changes ยุบใน index)
S3 — Activity Report (PRC)	`PRC`	(ใหม่ greenfield) → `PSDBPRDDB`	7.13	changes · schema.sql · data_dict · ERD · impl
S4 — eMediation (ไกล่เกลี่ย)	`MEDIATE`	`MEDIATE` (.149 PSDBPRDDB, มีอยู่แล้ว 95 ตาราง) → ขยายต่อ (DELTA) + รวม V1+V2 → single DB	7.14	changes · schema.sql · data_dict · ERD · impl (live as-is: ../s4_mediation)
S8 — Official Website	`WEB`	`RLPD_WEB` (.226, legacy) → `PSDBPRDDB`	7.18	changes · schema.sql · data_dict · ERD · impl
S9 — Web Portal	`PORTAL`	`PSDBPRDDB` (.149, มีอยู่แล้ว) → ขยายต่อ	7.19	changes · schema.sql · data_dict · ERD · impl

โครงสร้างเอกสาร (ต่อระบบ)¶

design_p2/
  index.md            # หน้านี้ — decisions + ลิงก์
  s8_website/
    index.md          # overview + REQ → table traceability matrix (spine)
    changes.md        # 📋 สิ่งที่ต่างจากระบบเดิม (เพิ่ม/เปลี่ยน/เอาออก/รวม)
    schema.sql        # T-SQL DDL เต็ม (primary artifact)
    data_dict.md      # data dictionary ทุกตาราง/คอลัมน์
    er_diagram.md     # mermaid ERD + tag reuse/modify/new
    implementation.md # 🛠️ backend blueprint: REQ→endpoint→service→ตาราง→migration
  s3_activity_report/
    (เหมือนกัน — 7 ไฟล์ ; greenfield ไม่มี migration)
  s9_webportal/
    (เหมือนกัน)

ความครอบคลุม (Comprehensive)

"ครอบคลุม" = ทุก requirement ใน SRS (REQ-WEB-001…007, REQ-WPT-001…009) มีแถวใน traceability matrix — map ไปอย่างน้อย 1 ตาราง หรือ ระบุชัดว่า "ไม่มีผลต่อ schema (จัดการที่ app/infra)" เช่น WCAG rendering, SSL termination, caching, performance monitoring · ดู matrix ในหน้า index ของแต่ละระบบ