Cách thêm cơ sở dữ liệu vào ứng dụng (mà không làm mất dữ liệu sau này)

Để thêm cơ sở dữ liệu vào ứng dụng, hãy chọn một cơ sở dữ liệu quan hệ được quản lý sẵn (Postgres là lựa chọn thường dùng), giữ chuỗi kết nối trong một bí mật phía máy chủ, tạo một bảng cho mỗi loại đối tượng ứng dụng lưu trữ, và để backend của bạn — không phải trình duyệt — là bên đọc và ghi dữ liệu vào đó. Nếu bạn xây dựng bằng một công cụ tạo ứng dụng bằng AI, thường bạn chỉ cần nói "lưu cái này vào cơ sở dữ liệu" và agent sẽ thiết lập bảng và mã nguồn; phần việc của bạn là mô tả dữ liệu thật rõ ràng và kiểm tra xem dữ liệu có thực sự được lưu lại hay không.

Hướng dẫn này giải thích khi nào bạn cần cơ sở dữ liệu, các lựa chọn chính, cách mô tả dữ liệu và những lỗi gây mất hoặc rò rỉ dữ liệu.

Khi nào ứng dụng của bạn cần cơ sở dữ liệu

Bạn cần cơ sở dữ liệu khi ứng dụng phải ghi nhớ điều gì đó sau khi trang đã đóng, hoặc chia sẻ dữ liệu giữa mọi người. Các dấu hiệu thường gặp:

• Khách truy cập gửi thông tin: một biểu mẫu, đăng ký, đặt lịch hoặc đơn hàng
• Người dùng có tài khoản với nội dung đã lưu riêng của họ
• Quản trị viên cần xem hoặc chỉnh sửa những gì người khác đã tạo
• Bạn muốn báo cáo hoặc thống kê theo thời gian

Bạn không cần cơ sở dữ liệu cho một trang tĩnh mà mọi người đều thấy cùng một nội dung, như trang giới thiệu cá nhân hoặc trang đích đơn giản. Nếu bạn chưa rõ cơ sở dữ liệu thực sự là gì, hãy đọc trước cơ sở dữ liệu là gì.

Các lựa chọn của bạn

Với hầu hết các ứng dụng web nhỏ và vừa, cơ sở dữ liệu quan hệ như Postgres là lựa chọn mặc định phù hợp. Nó xử lý tốt các mối quan hệ (một khách hàng có nhiều đơn hàng), giữ dữ liệu nhất quán, và cho phép bạn trả lời các câu hỏi sau này bằng SQL. Xem Postgres là gì để có phần giải thích đơn giản.

Mô tả dữ liệu trước khi xây dựng

Việc hữu ích nhất bạn có thể làm là viết ra các đối tượng mà ứng dụng lưu trữ và chúng liên kết với nhau như thế nào. Bạn không cần dùng thuật ngữ cơ sở dữ liệu. Ví dụ với một ứng dụng đặt lịch:

• Khách hàng: tên, email, số điện thoại
• Dịch vụ: tên, thời lượng, giá
• Lịch đặt: khách hàng nào, dịch vụ nào, thời gian bắt đầu, trạng thái (chờ xác nhận, đã xác nhận, đã hủy)

Như vậy là có ba bảng. "Khách hàng nào" và "dịch vụ nào" trở thành các liên kết (khóa ngoại) giữa chúng. Làm đúng việc này từ đầu quan trọng hơn bất kỳ lựa chọn công nghệ nào, vì thay đổi cấu trúc dữ liệu đã có dòng thật bên trong khó hơn nhiều so với thay đổi bố cục trang.

Một vài quy tắc tham khảo:

• Một bảng cho mỗi loại đối tượng. Đừng nhồi đơn hàng vào một cột văn bản trên bảng khách hàng.
• Mỗi dòng có một ID và thời điểm tạo. Bạn sẽ cần cả hai sau này.
• Dùng đúng kiểu dữ liệu. Ngày tháng lưu dạng ngày, tiền lưu dạng số nguyên (đơn vị nhỏ nhất) hoặc số thập phân, không lưu dạng văn bản.
• Đánh dấu trường bắt buộc. Hãy để cơ sở dữ liệu từ chối dữ liệu sai, không chỉ dựa vào biểu mẫu.

Các prompt mẫu

Hãy bắt đầu với một tính năng mỗi lần thay vì đưa cả sơ đồ lên một lúc:

Thêm cơ sở dữ liệu cho ứng dụng này. Tạo bảng bookings gồm tên khách hàng, email, dịch vụ, thời gian bắt đầu và trạng thái (chờ xác nhận, đã xác nhận, đã hủy; mặc định là chờ xác nhận). Lưu các biểu mẫu đặt lịch vào bảng này, hiển thị thông báo thành công, và thêm trang quản trị liệt kê các lịch đặt, mới nhất lên đầu.

Sau đó mở rộng:

Thêm bảng services (tên, thời lượng tính bằng phút, giá tính bằng xu). Thay trường dịch vụ dạng văn bản tự do trong bookings bằng liên kết tới services, và chuyển dữ liệu các lịch đặt hiện có mà không xóa chúng.

Và siết chặt hơn:

Đảm bảo mọi thao tác đọc và ghi cơ sở dữ liệu đều diễn ra trên máy chủ. Trình duyệt tuyệt đối không được nhận chuỗi kết nối cơ sở dữ liệu. Kiểm tra email và thời gian bắt đầu trên máy chủ trước khi chèn vào bảng.

Từng bước

1. Liệt kê dữ liệu như trên: đối tượng, trường, và liên kết giữa chúng.
2. Tạo cơ sở dữ liệu. Trong công cụ tạo ứng dụng bằng AI, yêu cầu trong chat. Ở nơi khác, tạo một instance Postgres được quản lý và sao chép chuỗi kết nối.
3. Lưu chuỗi kết nối như một bí mật (biến môi trường trên máy chủ), không bao giờ đặt trong mã nguồn. Xem biến môi trường và bí mật.
4. Tạo các bảng. Dùng migration — các script có phiên bản để thay đổi cấu trúc — để thay đổi có thể lặp lại và đảo ngược.
5. Xây dựng các route phía máy chủ để tạo, đọc, cập nhật và xóa dòng (CRUD). Trình duyệt gọi các route này; nó không bao giờ nói chuyện trực tiếp với cơ sở dữ liệu.
6. Kết nối giao diện với các route đó: biểu mẫu lưu dữ liệu, danh sách tải dữ liệu, và trạng thái trống khi chưa có gì.
7. Kiểm tra việc lưu trữ. Gửi một dữ liệu, tải lại trang, rồi mở ở một trình duyệt khác. Nếu dữ liệu không có ở đó, nghĩa là nó chưa được lưu vào cơ sở dữ liệu.
8. Kiểm tra quyền truy cập. Đăng nhập bằng người dùng thứ hai và xác nhận bạn không thể xem hoặc sửa dữ liệu của người dùng thứ nhất.
9. Xuất bản, sau đó kiểm tra lại trên URL thật, vì ứng dụng đã xuất bản có thể dùng kết nối khác với bản xem trước của bạn.

Những lỗi thường gặp

• Lưu vào trình duyệt rồi tưởng là đã lưu vào cơ sở dữ liệu. localStorage trông có vẻ hoạt động cho đến khi ai đó mở ứng dụng trên thiết bị khác. Luôn kiểm tra trên một trình duyệt thứ hai.
• Đặt chuỗi kết nối trong mã frontend. Ai cũng có thể đọc mã frontend. Điều đó cho họ toàn quyền truy cập cơ sở dữ liệu của bạn.
• Không kiểm tra quyền truy cập. "Hiển thị đơn hàng của tôi" phải lọc theo người dùng đang đăng nhập trên máy chủ, không phải trong giao diện. Đây là lỗ hổng bảo mật phổ biến nhất trong các ứng dụng xây bằng AI; danh sách kiểm tra bảo mật của chúng tôi có đề cập đến nó.
• Thay đổi cấu trúc gây mất dữ liệu. Yêu cầu "đổi tên bảng" hoặc "thay đổi cấu trúc" có thể xóa và tạo lại bảng. Khi đã có dữ liệu thật, hãy nói "chuyển các dòng hiện có, đừng xóa gì cả".
• Lưu tệp trong cơ sở dữ liệu. Hình ảnh và PDF thuộc về dịch vụ lưu trữ tệp, chỉ nên lưu URL hoặc khóa của chúng trong bảng. Xem cách thêm tải tệp lên.
• Không có bản sao lưu. Hãy biết nền tảng sao lưu dữ liệu như thế nào và cách khôi phục, trước khi bạn có khách hàng.

Danh sách kiểm tra

• Mỗi loại đối tượng có bảng riêng với ID và thời điểm tạo
• Trường bắt buộc và kiểu dữ liệu được cơ sở dữ liệu áp dụng
• Chuỗi kết nối chỉ nằm trong bí mật phía máy chủ
• Mọi thao tác đọc và ghi đều đi qua route phía máy chủ
• Mỗi người dùng chỉ đọc và thay đổi các dòng của chính mình
• Dữ liệu còn nguyên sau khi tải lại và hiển thị trên trình duyệt khác
• Thay đổi cấu trúc dùng migration và giữ nguyên các dòng hiện có
• Bạn biết cách sao lưu và khôi phục hoạt động ra sao
• Ứng dụng đang chạy đã được kiểm tra sau khi xuất bản

Thêm cơ sở dữ liệu trong Mythex

Trên Mythex, mỗi dự án có thể có một cơ sở dữ liệu Postgres riêng, cả trên gói Free và Pro. Thường bạn không cần nhấn nút "đính kèm" riêng: hãy yêu cầu trong chat ("lưu email danh sách chờ vào cơ sở dữ liệu") hoặc gõ /database, và thông tin kết nối sẽ được đưa vào không gian làm việc và ứng dụng đã xuất bản của bạn. Phần Cài đặt dự án cho biết cơ sở dữ liệu đã hoạt động hay chưa.

Cơ sở dữ liệu sẽ ngủ sau 5 phút không hoạt động và tự thức dậy ở yêu cầu tiếp theo. Mức sử dụng khi xuất bản được tính theo thời gian nó thực sự hoạt động, trừ từ cùng số dư credit bạn dùng để xây dựng. Nếu bạn thêm cơ sở dữ liệu sau khi đã xuất bản, hãy xuất bản lại để ứng dụng đang chạy nhận được nó.

Xem Cơ sở dữ liệu và công thức Xây dựng ứng dụng CRUD trong tài liệu. Về phần đăng nhập để dữ liệu thuộc từng người dùng, hãy đọc cách thêm đăng nhập vào ứng dụng.

Câu hỏi thường gặp