Chương 3: Tư duy Dữ liệu (Data Thinking) - Móng Chắc Nhà Mới Cao
"Dữ liệu là móng nhà. Móng không chắc, App xây cao sẽ đổ." - Hiền Nguyễn
Chào bạn, nếu có một lời khuyên chân thành nhất tôi dành cho bạn khi bắt đầu với AppSheet, thì đó là: Hãy quên Excel đi.
Nghe có vẻ cực đoan, đúng không? Nhưng kinh nghiệm triển khai hàng trăm dự án của tôi cho thấy, sai lầm lớn nhất của người mới không phải là không biết code, mà là mang nguyên tư duy## Từ "Bảng tính phẳng" đến "Database quan hệ"

Hầu hết chúng ta đều xuất thân từ Excel. Tư duy Excel là "Tư duy phẳng". ta thích gộp tất cả: Khách hàng, Đơn hàng, Sản phẩm vào chung một sheet dài ngoằng để "tiện nhìn". Nhưng trong thế giới App, đó là một thảm họa.
Chương này không chỉ là lý thuyết. Đây là tư duy sống còn.
3.1 Cuộc Di Cư Tư Duy: Từ "Biểu Mẫu" sang "Cấu Trúc"
Đừng bao giờ bắt đầu bằng việc vẽ giao diện hay nghĩ xem Form nhập liệu trông thế nào. Hãy bắt đầu từ câu hỏi: "Tôi đang quản lý những đối tượng nào?"
Ví dụ, bạn muốn làm App bán hàng.
- Tư duy cũ (Excel): "Tôi cần một cái bảng có cột Tên Khách, cột Sản Phẩm, cột Giá Tiền, cột Ngày Mua..." -> Kết quả: Dữ liệu lặp đi lặp lại, nhập sai tên khách, sai giá tiền liên tục.
- Tư duy AppSheet (Database): "Tôi có 3 đối tượng riêng biệt":
- Khách hàng (Customers): Thông tin tĩnh, lưu 1 lần dùng mãi mãi.
- Sản phẩm (Products): Danh mục cố định, ít thay đổi.
- Đơn hàng (Orders): Sự kiện phát sinh liên tục, kết nối Khách và Sản phẩm.
=> Lời khuyên: Hãy tập thói quen "chia để trị". Tách bảng đúng lúc giúp App của bạn nhẹ hơn, chuẩn xác hơn và dễ dàng mở rộng sau này.
3.2 Quy Chuẩn Đặt Tên: "Kỷ Luật Là Sức Mạnh"
Bạn có tin không, 50% lỗi công thức SELECT, LOOKUP sau này đến từ việc đặt tên cột cẩu thả? "Họ và tên", "Ngày sinh (dd/mm/yyyy)", "Tổng tiền"... Những cái tên có dấu, có khoảng trắng này là kẻ thù của lập trình.
Đây là quy chuẩn "bất di bất dịch" mà tôi áp dụng cho mọi dự án EMS Solution:
- Tên Bảng (Table Name): Tiếng Anh hoặc Tiếng Việt không dấu, viết liền. (Ví dụ:
CustomershoặcKhachHang). Cá nhân tôi khuyên dùng Tiếng Anh để tận dụng AI tốt hơn. - Tên Cột (Column Name): PascalCase (Viết hoa chữ cái đầu, không dấu, không khoảng trắng).
- (+) Tốt:
HoTen,NgaySinh,TongTien,Status. - (-) Xấu:
Họ tên,ngày sinh,Tổng tiền (VND).
- (+) Tốt:
- ID (Khóa chính): Đây là xương sống của bảng. Luôn đặt tên theo công thức
[TableName]ID.- Ví dụ: Bảng
Customers-> Cột khóa làCustomerID. BảngProducts->ProductID. - Tại sao? Vì khi bạn nhìn vào một cột
CustomerIDở bất kỳ bảng nào khác, bạn biết ngay nó trỏ về bảng Customers.
- Ví dụ: Bảng
3.3 Google Sheets, AppSheet Database hay SQL?
Một câu hỏi tôi nhận được mỗi ngày: "Dữ liệu nhiều có làm App chậm không?". Câu trả lời là: Có, nếu bạn chọn sai kho chứa.
| Tiêu chí | Google Sheets | AppSheet Database | Cloud SQL (SQL Server) |
|---|---|---|---|
| Bản chất | Bảng tính (Spreadsheet) | Cơ sở dữ liệu quan hệ (Native) | Cơ sở dữ liệu chuyên nghiệp |
| Dung lượng | Tốt cho < 20.000 dòng | Tốt cho < 50.000 dòng | Hàng triệu dòng |
| Tốc độ Sync | Trung bình (càng nhiều công thức càng chậm) | Nhanh | Rất nhanh |
| Độ khó | Dễ nhất (Ai cũng biết dùng) | Trung bình | Khó (Cần kiến thức IT) |
| Phù hợp với | SME, MVP, Dự án nhỏ | SME, Cần chuẩn hóa | Doanh nghiệp lớn (Enterprise) |
Lời khuyên thực chiến: Đừng phức tạp hóa vấn đề khi mới bắt đầu. Với dự án CRM đầu tay này, Google Sheets là lựa chọn hoàn hảo. Nó miễn phí, dễ chỉnh sửa, và quen thuộc. Khi nào doanh nghiệp của bạn có 100.000 đơn hàng, chúng ta sẽ bàn chuyện chuyển nhà sang SQL sau.
3.4 Trợ Lý Đắc Lực: AI Database Architect
Ngày xưa, tôi mất cả ngày để vẽ sơ đồ ERD (quan hệ dữ liệu). Giờ đây, bạn chỉ mất 30 giây. Đừng tự nghĩ cấu trúc từ con số 0, hãy đứng trên vai người khổng lồ.
Prompt mẫu tôi hay dùng:
"Tôi muốn xây dựng ứng dụng [Tên App] trên AppSheet. Hãy đóng vai chuyên gia Database, gợi ý cấu trúc các bảng cần thiết, tên cột (chuẩn PascalCase) và kiểu dữ liệu tương ứng. Yêu cầu chuẩn hóa dữ liệu để tránh lặp lặp."
Kết quả AI trả về thường đúng tới 80%. Việc của bạn là tinh chỉnh 20% còn lại cho phù hợp với nghiệp vụ riêng.
3.5 Thực Hành & Vận Dụng
3.5.1 Bài tập: Chuẩn hóa dữ liệu CRM
Hãy mở Google Gemini hoặc ChatGPT và thử ngay Prompt trên cho ứng dụng CRM quản lý Khách hàng tiềm năng (Leads) và Cơ hội bán hàng (Opportunities).
So sánh kết quả AI gợi ý với tư duy của bạn:
- AI có tách bảng
Activities(Lịch sử chăm sóc) riêng không? -> Nếu có, đó là một cấu trúc tốt để quản lý lịch sử gọi điện, gặp gỡ. - File Excel hiện tại của bạn có đang gộp chung "Thông tin Khách" và "Thông tin Đơn" không? -> Hãy tách chúng ra ngay lập tức.
- Kiểm tra lại toàn bộ tên cột trong file Google Sheet của bạn. Đã chuẩn
PascalCasechưa? Đã có cộtIDchưa?
3.6 Đúc kết: Dữ liệu là tài sản, không phải bảng tính
Dữ liệu là linh hồn của ứng dụng. Bạn vừa học cách thổi hồn cho nó bằng tư duy hệ thống thay vì tư duy bảng tính phẳng. Việc chuẩn hóa tên cột, tách bảng hay sử dụng AI để thiết kế không chỉ giúp App chạy mượt hơn mà còn giúp bạn dễ dàng nâng cấp hệ thống sau này.
Nhưng Database mới chỉ là bộ khung xương thô. Để AppSheet thực sự "hiểu" được những dữ liệu đó - đâu là số điện thoại để bấm gọi, đâu là tọa độ để định vị bản đồ, hay đâu là file ảnh để hiển thị - chúng ta cần định danh chính xác cho chúng.
Hãy lật sang Chương 4, tôi sẽ hướng dẫn bạn làm chủ các Kiểu dữ liệu (Data Types) - chìa khóa để biến những dòng text vô tri thành các tính năng mobile mạnh mẽ.