Database
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> Database

Tạo mô hình nâng cao hơn với trạng thái người dùng, chủ đề và bài đăng

Trong bài viết đầu tiên của tôi về một diễn đàn trực tuyến, tôi đã đề cập rằng có thể có một số tính năng nâng cao hơn để thêm vào:

  • Thêm chi tiết chính thức về người dùng thay vì một trường "tên". Bạn có thể muốn tên, họ và tên người dùng hoặc biệt hiệu của người dùng. Một diễn đàn tốt đẹp cũng sẽ cho phép người dùng có ảnh hồ sơ, email, vai trò, trạng thái (cho phép người dùng bị chặn) và các thông tin khác như khi họ truy cập diễn đàn lần cuối.
  • Kiểm soát bổ sung liên quan đến tạo người dùng để chúng tôi có thể theo dõi thời điểm người dùng mới được tạo nhưng trước khi địa chỉ email của họ được xác nhận.
  • Diễn đàn danh mục và các danh mục phụ trong đó mỗi danh mục có một chủ đề, một số người kiểm duyệt và thông tin bổ sung như ngày tạo danh mục. Chủ đề cho một bài đăng bổ sung cho nội dung
  • Bài đăng được kiểm duyệt phải được người kiểm duyệt phê duyệt trước khi chúng hiển thị với những người dùng khác. Các bài đăng và chủ đề sẽ có các trạng thái khác nhau như:đang chờ xuất bản, đã xuất bản, được báo cáo là spam, bị chặn, bỏ chặn.
  • Và sau đó, chúng tôi có thể muốn cho phép người dùng bỏ phiếu bỏ phiếu chủ đề và bài đăng.

Đối với diễn đàn, tôi sẽ sử dụng thuật ngữ “chủ đề” để chỉ một cuộc trò chuyện có khả năng có một số bài đăng liên quan đến chủ đề đó.




Tôi sẽ đưa ra lời bình luận mở đầu; Tôi thường sử dụng các số tròn như 100 hoặc 1000 để xác định độ dài của các trường varchar; Tôi không gợi ý rằng đây nhất thiết phải là kích thước thích hợp, nhưng tôi đang sử dụng nó như là tốc ký, thay vì để độ dài không xác định (%). Mặt khác, đôi khi tôi sử dụng độ dài rất cụ thể cho các trường như emailip_address; 254 là độ dài tối đa mà một địa chỉ email có thể có theo định nghĩa RFC, trong khi 45 là độ dài tối đa mà một địa chỉ IPv6 có thể có.

Chi tiết Người dùng

Trong Phần 1 của loạt bài viết của chúng tôi về xây dựng diễn đàn trực tuyến, thông tin về người dùng rất hạn chế. Tôi sẽ nâng cao chi tiết người dùng được lưu trữ. Hiện tại, việc kiểm duyệt sẽ rất cơ bản:người dùng sẽ là người kiểm duyệt hoặc không. Sau này, chúng tôi có thể tạo các quy tắc kiểm duyệt phức tạp hơn liên quan đến danh mục và chuỗi.

Đối với trạng thái của người dùng, tôi sẽ tạo user_status để tôi có thể sử dụng lại bảng đó trong một tình huống khác ngay cả khi có rất ít trạng thái, như “EMAIL_NOT_VERIFIED”, “VERIFIED” và “BLOCKED”.

Tạo người dùng

Tôi sẽ sử dụng trạng thái của người dùng để nhận ra những người dùng ở trạng thái “EMAIL_NOT_VERIFIED” sau khi người dùng đã tạo tài khoản của họ và một email đã được gửi đến địa chỉ email đã cho của họ, nhưng trước khi họ nhấp vào URL xác minh trong email. Bạn thậm chí có thể gặp khó khăn hơn và có các trạng thái như “EMAIL_VERIFICATION_TO_BE_SENT” và “EMAIL_VERIFICATION_RESENT” nếu một số bước này được xử lý bởi các thành phần khác nhau trong hệ thống của bạn chứ không phải ngay lập tức trong quá trình tạo người dùng.

Trạng thái chủ đề và bài đăng

Các bài đăng được kiểm duyệt phải được người kiểm duyệt phê duyệt trước khi chúng được hiển thị cho những người dùng khác. Các bài đăng và chủ đề sẽ có các trạng thái khác nhau như:đang chờ phê duyệt, được phê duyệt, được báo cáo là spam, bị chặn. Đối với trạng thái của chủ đề và bài đăng, tôi sẽ chọn một cách linh hoạt hơn để xử lý trạng thái bằng cách liên kết với status bàn. Sau đó, ứng dụng phải biết ý nghĩa của từng giá trị trong các bảng trạng thái (nếu status =“APPROVED”, chuỗi được hiển thị), nhưng tôi thích điều này hơn là chỉ lưu trữ một văn bản trong threadpost những cái bàn. Chúng tôi sẽ có một số trạng thái, như “WAITING_FOR_APPROVAL”, “APPROVED”, “REJECTED”, “REPORTED_AS_SPAM” và “BLOCKED” và chúng tôi có thể muốn thêm nhiều trạng thái khác trong tương lai.

Nói cách khác, người dùng tạo một chủ đề mới hoặc một bài đăng mới và nó được đưa vào trạng thái “NOT_APPROVED”. Các chủ đề và bài đăng không được phê duyệt không được hiển thị cho hầu hết người dùng; tuy nhiên, người kiểm duyệt có thể xem các mục không được phê duyệt và chọn “Phê duyệt” hoặc “Từ chối”. Người dùng có thể đánh dấu một chủ đề hoặc bài đăng là spam, nhưng điều đó phải được người kiểm duyệt xác nhận. Các chủ đề và bài đăng spam không được hiển thị cho người dùng.

Điều này cho phép tôi sử dụng status bảng cho cả chủ đề và bài đăng, vì trạng thái cho cả hai điều này phải có cùng ý nghĩa. Tôi sẽ không lạm dụng status bảng để chỉ ra trạng thái của người dùng; Tôi không nghĩ đó sẽ là một lựa chọn thiết kế tốt.

Thiết kế trang trọng

Vì vậy, chúng tôi mở rộng ERD đã được tạo trong Phần 1. Tôi đã tô màu các bảng đã được tạo trong bài viết Phần 1 bằng màu vàng và tô màu các bảng mới thêm bằng màu cam để dễ nhìn thấy các phần bổ sung hơn. Tuy nhiên, tôi chưa đánh dấu các thay đổi riêng lẻ trong các bảng.



Tiếp theo là gì?

Một lần nữa, vẫn còn những cải tiến bổ sung cần được thực hiện, nhưng ở đây chúng tôi đã tạo một diễn đàn trực tuyến rất đơn giản và bổ sung một số tính năng mới hữu ích.

Trong phần tiếp theo, tôi sẽ xem xét thêm các tính năng khác như:

  • diễn đàn danh mục và các danh mục phụ trong đó mỗi danh mục có một chủ đề, một số người kiểm duyệt và thông tin bổ sung như ngày tạo danh mục. A chủ đề cho một bài đăng ngoài nội dung
  • và sau đó, chúng tôi có thể muốn cho phép người dùng bình chọn và bỏ phiếu cho các chủ đề và bài đăng.

Diễn đàn trực tuyến của bạn yêu cầu những tính năng nào? Có tính năng nào bạn muốn tôi tính đến khi chuẩn bị phần tiếp theo của loạt bài này không? Nếu vậy, hãy cho tôi biết.

«Phần trước Phần tiếp theo »


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Quy trình được lưu trữ để có được cài đặt phiên bản

  2. NULL phức tạp - Phần 4, Thiếu ràng buộc duy nhất tiêu chuẩn

  3. Sử dụng dữ liệu được bảo vệ bằng Azure Key Vault từ Linux

  4. Triển khai Cơ sở dữ liệu từ Kiểm soát Nguồn

  5. Các TVF đa câu lệnh trong Dynamics CRM