Claude thiết kế Database Schema — Từ requirements đến ERD

Thiết kế database schema là một trong những quyết định kiến trúc quan trọng nhất trong bất kỳ dự án phần mềm nào. Schema tốt giúp ứng dụng hoạt động hiệu quả, dễ mở rộng và bảo trì. Schema tồi tạo ra technical debt tích lũy theo thời gian, gây chậm query, phức tạp code và khó thay đổi. Claude có thể hỗ trợ bạn trong toàn bộ quy trình thiết kế — từ phân tích requirements, đề xuất entity relationship, đến sinh CREATE TABLE statements và migration scripts.

Quy trình thiết kế schema với Claude

Quy trình thiết kế database schema bao gồm 5 bước chính: thu thập requirements, xác định entities và relationships, normalization, tạo physical schema và viết migration scripts. Claude có thể hỗ trợ ở mỗi bước, nhưng hiệu quả nhất khi bạn cung cấp business requirements rõ ràng ngay từ đầu.

Bước 1: Từ business requirements đến entities

Bước đầu tiên là chuyển đổi yêu cầu nghiệp vụ thành các entity và mối quan hệ. Đây là nơi Claude phát huy thế mạnh — phân tích ngôn ngữ tự nhiên và trích xuất các thực thể, thuộc tính và ràng buộc.

Thiết kế database schema cho hệ thống e-commerce B2C
với các yêu cầu nghiệp vụ sau:

1. USERS:
   - Đăng ký bằng email hoặc số điện thoại
   - Có thể có nhiều địa chỉ giao hàng (1 default)
   - Profile: tên, avatar, ngày sinh, giới tính
   - Lịch sử mua hàng và wishlist

2. PRODUCTS:
   - Thuộc 1 category (categories có parent-child, max 3 levels)
   - Có nhiều variants (size, color) với giá và stock riêng
   - Nhiều hình ảnh (1 primary)
   - Attributes động (tùy category: điện thoại có RAM, giày có size EU)
   - Reviews và ratings từ users đã mua

3. ORDERS:
   - Gồm nhiều order items từ nhiều sellers
   - Trạng thái: pending -> confirmed -> shipping -> delivered -> completed
   - Mỗi item có thể có trạng thái riêng (partial delivery)
   - Áp dụng voucher (% hoặc fixed amount, per order hoặc per item)
   - Lưu snapshot giá tại thời điểm đặt hàng

4. PAYMENTS:
   - Nhiều payment methods: COD, bank transfer, e-wallet
   - 1 order có thể có nhiều payment transactions (partial payment, refund)
   - Lưu payment gateway response

5. SELLERS:
   - Multi-vendor marketplace
   - Seller có shop profile, ratings
   - Commission rates khác nhau per category

Database: PostgreSQL 15
Ước tính: 1 triệu users, 500k products, 5 triệu orders/năm

Hãy:
1. Liệt kê tất cả entities và relationships (ERD dạng text)
2. Giải thích các quyết định thiết kế quan trọng
3. Chỉ ra những chỗ cần trade-off và đề xuất

Claude sẽ phân tích requirements và trích xuất khoảng 15-20 entities với các relationships rõ ràng. Điểm quan trọng là Claude không chỉ liệt kê entities mà còn chỉ ra các edge cases và quyết định thiết kế cần cân nhắc, ví dụ: nên dùng EAV pattern hay JSONB cho dynamic attributes, polymorphic association cho payment methods, hoặc event sourcing cho order status tracking.

Bước 2: Normalization

Sau khi có danh sách entities, bước tiếp theo là chuẩn hóa schema. Claude có thể kiểm tra schema của bạn theo các normal forms và đề xuất điều chỉnh.

Kiểm tra schema sau theo các quy tắc normalization:

[Dán CREATE TABLE statements hoặc mô tả schema]

Hãy phân tích:
1. Schema hiện tại đạt normal form nào? (1NF, 2NF, 3NF, BCNF)
2. Vi phạm normalization ở đâu? Cụ thể:
   - Repeating groups (vi phạm 1NF)
   - Partial dependencies (vi phạm 2NF)
   - Transitive dependencies (vi phạm 3NF)
3. Đề xuất schema đã normalize đến 3NF
4. Trường hợp nào nên giữ denormalized và tại sao
5. Functional dependencies diagram

Normalization vs Denormalization

Trong thực tế, schema hoàn toàn normalize không phải lúc nào cũng tối ưu. Claude có thể giúp bạn cân nhắc trade-off và quyết định khi nào nên denormalize.

Schema e-commerce đã normalize đến 3NF như sau:

[Dán schema]

Tuy nhiên, một số query quan trọng cần JOIN nhiều bảng
và chạy chậm:

Query 1 (Product listing page - 2000 calls/min):
Cần: product name, primary image, price range (min/max across variants),
     category name, seller name, avg rating, review count

Query 2 (Order detail page - 500 calls/min):
Cần: order info, all items with product name + image,
     customer info, payment status, shipping tracking

Hãy đề xuất:
1. Denormalization nào hợp lý để tăng read performance?
2. Cách duy trì data consistency sau denormalization
   (triggers, application-level, materialized views)
3. Trade-off: storage cost, write complexity, read speed
4. Khi nào dùng computed columns vs denormalized columns
   vs materialized views vs cache layer

Sinh CREATE TABLE statements

Sau khi hoàn thành thiết kế logic, Claude sinh ra physical schema hoàn chỉnh với data types, constraints, indexes và comments.

Sinh CREATE TABLE statements cho schema e-commerce đã thiết kế.

Yêu cầu:
1. PostgreSQL 15 syntax
2. Data types phù hợp:
   - Dùng BIGSERIAL cho primary keys
   - TIMESTAMPTZ cho timestamps
   - DECIMAL(15,2) cho tiền tệ
   - JSONB cho dynamic data
   - Enum types cho status fields
3. Constraints đầy đủ:
   - PRIMARY KEY, FOREIGN KEY (với ON DELETE action)
   - NOT NULL, UNIQUE, CHECK constraints
   - Default values hợp lý
4. Indexes:
   - Primary key (auto)
   - Foreign keys
   - Columns thường dùng trong WHERE/ORDER BY
   - Composite indexes cho common query patterns
   - Partial indexes nếu phù hợp
5. Comments cho mỗi table và column quan trọng
6. Sắp xếp theo dependency order (tạo bảng parent trước child)

Schema cần hỗ trợ:
- Soft delete (deleted_at column)
- Audit trail (created_at, updated_at, created_by)
- Multi-tenancy ready (có thể thêm tenant_id sau)

Claude sẽ sinh ra toàn bộ CREATE TABLE statements theo đúng dependency order, kèm theo các CREATE INDEX, CREATE TYPE (cho enum) và COMMENT statements. Đặc biệt, Claude sẽ thêm các CHECK constraints hữu ích mà developer thường bỏ qua, ví dụ CHECK (price >= 0), CHECK (quantity > 0), CHECK (email ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+.[A-Za-z]{2,}$').

Migration Scripts

Trong dự án thực tế, schema không tồn tại cố định mà liên tục thay đổi theo business requirements mới. Migration scripts giúp bạn track và apply schema changes một cách có kiểm soát.

Initial migration

Tạo migration script cho schema e-commerce trên.
Framework: [chọn 1: Prisma / TypeORM / Sequelize / Alembic / Flyway / Rails]

Yêu cầu:
1. Migration file theo convention của framework
2. Up migration: tạo tables, indexes, constraints
3. Down migration: rollback an toàn
4. Seed data cho reference tables (categories, payment methods, statuses)
5. Idempotent: chạy lại không lỗi

Schema evolution

Tôi cần thay đổi schema hiện tại để hỗ trợ tính năng mới:
"Subscription orders" - khách hàng đặt hàng định kỳ tự động.

Yêu cầu nghiệp vụ mới:
- User tạo subscription cho 1 hoặc nhiều products
- Frequency: weekly, bi-weekly, monthly
- Tự động tạo order theo schedule
- User có thể pause/resume/cancel subscription
- Áp dụng discount cho subscription orders
- Thay đổi quantity hoặc products trong subscription

Schema hiện tại:
[Dán schema hiện tại]

Hãy:
1. Thiết kế bảng mới cần tạo
2. Thay đổi bảng hiện tại (nếu cần)
3. Migration script (up + down)
4. Đảm bảo backward compatible
5. Data migration nếu cần chuyển đổi data cũ
6. Zero-downtime migration strategy

Ví dụ thực tế: Schema cho hệ thống SaaS

Ngoài e-commerce, một ví dụ phổ biến khác là thiết kế schema cho ứng dụng SaaS multi-tenant.

Thiết kế database schema cho ứng dụng SaaS quản lý dự án
(tương tự Jira/Linear) với yêu cầu:

1. MULTI-TENANCY:
   - Mỗi organization là 1 tenant
   - Data isolation: shared database, shared schema
   - Row-level security với tenant_id

2. ORGANIZATIONS & TEAMS:
   - Organization có nhiều teams
   - User thuộc nhiều organizations với roles khác nhau
   - Invite system với email

3. PROJECTS & ISSUES:
   - Project thuộc 1 team
   - Issue có: title, description (rich text),
     status, priority, assignee, labels, sprint
   - Custom fields per project (dropdown, text, number, date)
   - Parent-child relationship (epic -> story -> subtask)
   - Comments với mentions (@user)
   - Attachments (metadata only, files on S3)

4. WORKFLOWS:
   - Custom status workflow per project
   - Status transitions có rules (e.g., chỉ QA mới được move to Done)
   - Auto-assignment rules

5. ACTIVITY & AUDIT:
   - Mọi thay đổi trên issue được log (ai, thay đổi gì, khi nào)
   - Activity feed per issue, per project, per user

Database: PostgreSQL 15
Multi-tenancy strategy: shared schema with RLS
Ước tính: 10K tenants, 100K users, 50M issues

Hãy thiết kế schema hoàn chỉnh bao gồm:
- ERD diagram (dạng text)
- CREATE TABLE statements
- Row Level Security policies
- Giải thích architectural decisions

Patterns thiết kế schema phổ biến

Claude nắm vững nhiều design patterns trong database schema. Dưới đây là một số pattern bạn có thể yêu cầu Claude áp dụng.

Polymorphic Associations

Tôi cần thiết kế bảng comments mà có thể attach vào
nhiều loại entity khác nhau: products, articles, orders.

So sánh 3 approaches:
1. Polymorphic (commentable_type + commentable_id)
2. Separate join tables (product_comments, article_comments)
3. Single table với nullable FKs

Cho mỗi approach: ưu nhược điểm, query patterns,
performance trên 10M comments, data integrity guarantees.

Database: PostgreSQL 15
Recommend approach nào và tại sao.

Temporal Data (History Tracking)

Tôi cần track lịch sử thay đổi giá sản phẩm.
Mỗi lần thay đổi giá cần lưu: giá cũ, giá mới,
ai thay đổi, lý do, thời gian hiệu lực.

So sánh approaches:
1. History table riêng (product_price_history)
2. Temporal table (system-versioned, nếu DB hỗ trợ)
3. Event sourcing pattern
4. JSONB changelog column

Yêu cầu queries:
- Giá hiện tại của product (query nhiều nhất)
- Giá tại thời điểm T (cho order historical reporting)
- Lịch sử thay đổi giá (cho admin dashboard)

Database: PostgreSQL 15
Đề xuất schema và query cho mỗi use case.

Hierarchical Data (Tree Structure)

Thiết kế schema cho category tree (max 5 levels depth):

So sánh các approaches:
1. Adjacency List (parent_id)
2. Nested Sets (lft, rgt)
3. Materialized Path (path: '1/3/7/15')
4. Closure Table
5. ltree extension (PostgreSQL)

Use cases cần hỗ trợ:
- Lấy tất cả children (bao gồm nested) của 1 category
- Lấy breadcrumb path từ root đến leaf
- Move subtree sang parent khác
- Count products trong category (bao gồm sub-categories)
- Category có 5000 nodes, max depth 5

Đề xuất approach tốt nhất cho PostgreSQL 15
kèm schema và query cho mỗi use case.

Data Integrity và Constraints

Một schema tốt không chỉ có cấu trúc đúng mà còn phải đảm bảo data integrity thông qua constraints. Claude có thể review schema và bổ sung các constraints quan trọng.

Review schema sau và bổ sung constraints để đảm bảo data integrity:

[Dán CREATE TABLE statements]

Kiểm tra và thêm:
1. NOT NULL cho columns bắt buộc
2. UNIQUE constraints (đơn lẻ và composite)
3. CHECK constraints cho business rules:
   - Giá >= 0
   - Quantity > 0
   - Email format hợp lệ
   - Status chỉ nhận giá trị cho phép
   - start_date < end_date
4. FOREIGN KEY với ON DELETE action phù hợp:
   - CASCADE cho child records
   - SET NULL cho optional references
   - RESTRICT cho critical references
5. DEFAULT values hợp lý
6. EXCLUSION constraints (nếu cần, ví dụ booking không overlap)
7. Triggers cho business logic phức tạp không thể dùng constraints

Performance Considerations khi thiết kế schema

Claude cũng giúp bạn cân nhắc performance ngay từ giai đoạn thiết kế, không đợi đến khi gặp vấn đề mới tối ưu.

Review schema sau về performance cho workload dự kiến:

[Dán schema]

Workload profile:
- Read/Write ratio: 80/20
- Peak concurrent users: 5000
- Top queries: [mô tả 5 query quan trọng nhất]
- Data growth: 1 triệu rows/tháng cho bảng chính

Hãy đánh giá:
1. Data types có tối ưu storage không?
   (ví dụ: VARCHAR(255) vs TEXT, INT vs BIGINT)
2. Có cần partitioning cho bảng nào không?
3. Index strategy phù hợp với query patterns
4. JSONB vs normalized tables cho flexible data
5. Connection pooling considerations
6. Vacuum và bloat management strategy

Prompt Templates tổng hợp

Quick schema review

Review database schema sau:

[Dán schema]

Đánh giá về:
1. Normalization level và vi phạm (nếu có)
2. Data integrity (constraints thiếu)
3. Naming convention consistency
4. Index coverage cho common queries
5. Scalability concerns
6. Top 3 cải thiện quan trọng nhất

Schema comparison

So sánh 2 schema designs sau cho cùng requirements:

Design A:
[Dán schema A]

Design B:
[Dán schema B]

So sánh theo:
1. Query complexity cho [liệt kê use cases]
2. Write performance
3. Storage efficiency
4. Flexibility cho thay đổi requirements
5. Data integrity guarantees
6. Recommend design nào và tại sao

Database Partitioning Strategy

Khi bảng vượt quá hàng chục triệu rows, partitioning trở thành chiến lược quan trọng để duy trì performance. Claude có thể giúp bạn chọn partitioning strategy phù hợp và implement đúng cách.

Thiết kế partitioning strategy cho bảng orders:

Table: orders (hiện tại 50 triệu rows, tăng 2 triệu/tháng)
Database: PostgreSQL 15

Query patterns:
- 90% queries filter theo created_at (recent data)
- Reports cần aggregate theo tháng/quý
- Lookup by order_id cần nhanh
- Archival: data cũ hơn 2 năm ít khi access

So sánh approaches:
1. Range partitioning theo created_at (monthly)
2. Range partitioning theo created_at (quarterly)
3. List partitioning theo status + range theo date
4. Hash partitioning theo order_id

Cho mỗi approach:
- CREATE TABLE statements
- Index strategy trên partitioned table
- Cách tự động tạo partition mới (pg_partman)
- Query performance impact
- Maintenance operations (VACUUM, ANALYZE per partition)
- Data archival strategy (detach old partitions)

Recommend approach tốt nhất và giải thích.

Multi-database Architecture

Nhiều ứng dụng hiện đại sử dụng nhiều loại database cho các use case khác nhau. Claude có thể giúp bạn thiết kế data architecture phù hợp.

Thiết kế data architecture cho ứng dụng với yêu cầu:

1. Transactional data (orders, users, products):
   PostgreSQL - ACID compliance, complex queries

2. Session và cache:
   Redis - fast reads, TTL support

3. Full-text search:
   Elasticsearch - product search, autocomplete

4. Analytics:
   ClickHouse hoặc BigQuery - aggregation queries

Hãy thiết kế:
1. Schema cho mỗi database
2. Data synchronization strategy giữa các databases
3. Consistency guarantees (eventual vs strong)
4. Cách handle failure khi 1 database down
5. CDC (Change Data Capture) pipeline design
6. Query routing logic (read from which database?)

Best Practices khi dùng Claude thiết kế schema

• Cung cấp business context: Claude thiết kế tốt hơn khi hiểu nghiệp vụ, không chỉ technical requirements. Mô tả use cases, user flows và query patterns dự kiến
• Iterative design: Bắt đầu với high-level entities, review với Claude, rồi chi tiết hóa từng phần. Không cố gắng thiết kế toàn bộ schema trong 1 lần
• Review với team: Claude đề xuất schema, nhưng quyết định cuối cùng phải dựa trên context cụ thể của dự án mà chỉ team của bạn mới nắm rõ
• Plan for change: Yêu cầu Claude thiết kế schema có khả năng mở rộng. Soft delete, audit columns và flexible data structures (JSONB) giúp giảm migration cost
• Test với realistic data: Sau khi có schema, tạo test data với volume tương tự production và chạy thử các query quan trọng

Bước tiếp theo

Bạn đã nắm được quy trình thiết kế database schema với sự hỗ trợ của Claude — từ phân tích requirements, normalization, sinh CREATE TABLE statements đến migration scripts. Schema design là kỹ năng cần thực hành liên tục, và Claude là công cụ hỗ trợ giúp bạn đưa ra quyết định thiết kế tốt hơn. Khám phá thêm các hướng dẫn tại Thư viện Ứng dụng Claude.