Giới thiệu
Mọi ứng dụng thực tế đều cần ba lớp: nơi lưu trữ dữ liệu, các quy tắc quyết định điều gì xảy ra khi dữ liệu thay đổi, và cách phản ứng. Trong codebase truyền thống, bạn sẽ viết migration SQL, ORM, controller và cron job. Phương pháp no-code thay thế những thứ đó bằng các khối xây dựng trực quan cho ra cùng kết quả. Trong bài học này, bạn sẽ chọn một công cụ cơ sở dữ liệu, mô hình hóa hai bảng có liên kết và kết nối một workflow chạy mỗi khi một dòng được tạo. Chúng ta sẽ dùng Airtable làm ví dụ chính vì grid view giúp kiểm tra các mối quan hệ dễ dàng, nhưng các mẫu thiết kế tương tự cũng áp dụng cho Supabase, Baserow hoặc Xano.
Thiết lập base đầu tiên của bạn
Một base là vùng chứa cấp cao nhất chứa các bảng của bạn. Bên trong base, mỗi bảng là một lưới dạng bảng tính trong đó mỗi cột là một trường có kiểu dữ liệu. Hãy nghĩ kiểu trường là câu hỏi bạn đặt ra cho một dòng: trường Single Line Text hỏi một chuỗi ngắn, trường Number bắt buộc là chữ số, trường Date lưu giá trị lịch, và trường Linked Record trỏ đến một dòng trong bảng khác. Chọn đúng kiểu trường ngay từ đầu giúp ngăn dữ liệu sai xâm nhập vào hệ thống.
Mở Airtable, tạo một base tên "Bookings" và thêm hai bảng: "Customers" và "Appointments". Bên trong Customers, thêm các trường sau:
Bây giờ chuyển sang bảng Appointments và thêm:
Lưu ý trường Customer không phải là trường text thuần sao chép tên. Nó là một liên kết, nghĩa là xóa dòng khách hàng sẽ cảnh báo bạn, lọc view theo khách hàng là tức thì, và các trường rollup có thể kéo điểm thưởng sang.
Định nghĩa các mối quan hệ dữ liệu
Có ba dạng quan hệ bạn sẽ dùng đi dùng lại trong mọi dự án. Một-nhiều nghĩa là một dòng cha sở hữu nhiều dòng con — một khách hàng có thể có nhiều cuộc hẹn. Nhiều-nhiều cần một bảng trung gian — một stylist có thể phục vụ nhiều dịch vụ, và một dịch vụ có thể được thực hiện bởi nhiều stylist. Một-một hiếm gặp và thường báo hiệu hai trường nên nằm chung một bảng.
Trong Airtable, trường Linked Record mặc định là một-nhiều. Để nó hoạt động theo kiểu nhiều-nhiều, hãy cho phép liên kết nhiều bản ghi ở cả hai phía, và Airtable sẽ tự tạo bảng trung gian. Schema cho cầu nối Stylist-Service sẽ trông như sau:
Trường đối xứng ở mỗi phía chính là thứ làm cho quan hệ có thể truy vấn theo cả hai chiều. Nếu chỉ một phía có liên kết, truy vấn từ phía còn lại sẽ âm thầm trả về rỗng — một nguồn lỗi phổ biến kiểu "workflow của tôi không chạy".
Xây dựng workflow trực quan
Workflow là một chuỗi trigger và hành động chạy mà bạn không cần viết mã. Trigger phổ biến nhất là "Khi một bản ghi được tạo" trong một bảng cụ thể. Các hành động phổ biến nhất là "Gửi email", "Tạo bản ghi trong bảng khác" và "Cập nhật bản ghi". Một workflow thực tế cho ứng dụng đặt lịch của chúng ta là: khi một dòng Appointment mới được tạo, tự động cập nhật Loyalty Points của Customer tương ứng bằng cách cộng thêm Price của cuộc hẹn.
Trong Airtable Automations, cấu hình trông như sau:
Các token dạng ngoặc nhọn là cách bạn truyền giá trị trường giữa các bước. Chúng được đánh giá tại thời điểm chạy, vì vậy nếu sau này bạn đổi tên trường, bạn phải chọn lại trong bộ chọn token nếu không workflow sẽ hỏng. Luôn kiểm thử với một dòng mẫu trước khi bật automation cho toàn bộ bảng — automation kích hoạt trên mọi dòng lịch sử tương đương với một đoạn script chạy không kiểm soát.
Các lỗi thường gặp và kiểm tra nhanh
Ba mẫu lỗi chiếm phần lớn sự cố trong backend no-code. Thứ nhất, dùng trường Single Line Text ở nơi cần Linked Record — bạn mất tính toàn vẹn tham chiếu và rollup ngừng hoạt động. Thứ hai, xây dựng logic phụ thuộc vào trường không rỗng mà không thêm nhánh điều kiện, gây lỗi âm thầm khi dòng trigger không đầy đủ. Thứ ba, xâu chuỗi hơn bốn hành động trong một workflow mà không kiểm thử riêng từng bước; nếu bước ba thất bại, bạn không thể biết bước một và hai đã làm đúng việc của chúng hay chưa.
Một thói quen debug đáng tin cậy là thêm hành động cuối cùng "Gửi email cho chính bạn" tóm tắt mọi biến mà workflow nhìn thấy. Chỉ một dòng đó bắt được 80% lỗi sai trường vì nội dung email hiển thị giá trị token thực tế đã được thay thế.
Tóm tắt
Bạn đã thiết lập một base với hai bảng, mô hình hóa liên kết một-nhiều giữa Customers và Appointments, và tạo một automation cập nhật điểm thưởng mỗi khi cuộc hẹn được ghi nhận. Mô hình tư duy cần giữ là: bảng lưu trữ sự kiện, trường liên kết mã hóa quan hệ, và automation mã hóa phản ứng. Bài học ngày mai sẽ phơi bày cùng dữ liệu này cho một trình tạo giao diện front-end để người dùng có thể tương tác qua một UI thực sự.
Bài kiểm tra cuối bài
Ôn lại kiến thức, thử sức và nhận góp ý cho bài làm.