2011-10-25 34 views
5

Tôi đã làm việc trên một dự án đòi hỏi phải có dự thảo/phiên bản sống của nội dung và đã nghĩ đến một thiết kế như sau:Draft/Nội dung trực tuyến Cơ sở dữ liệu Thiết kế hệ thống

Article 
    ID 
    Creator 
    CreationDate 
    DraftContent(fk to ArticleContent) 
    PublicContent(fk to ArticleContent) 
    IsPendingApproval 

ArticleContent 
    Title 
    Body 

Tôi tự hỏi nếu nó sẽ là tốt hơn để thay đổi các khóa nước ngoài khi một bài báo được xuất bản hoặc nếu tốt hơn là chỉ cần sao chép nội dung từ bảng dự thảo sang bảng trực tiếp.

Mọi đề xuất?

Chỉnh sửa: Cả bản nháp và phiên bản trực tiếp đều tồn tại cùng một lúc mặc dù phiên bản trực tiếp là phiên bản duy nhất hiển thị công khai. Chỉ có thể có một bản nháp và một bảng trực tiếp

Một phần lý do cho thiết kế này là buộc người dùng phải chấp thuận các bài viết của họ trước khi chúng được phát hành trực tiếp.

Cập nhật:

Chúng tôi quyết định sử dụng giải pháp của Kieren với sửa đổi nhỏ. Thay vì sử dụng một cột cho các mục như IsPublished IsLive, chúng tôi quyết định sử dụng một cột trạng thái đơn. Nếu không, thiết kế vẫn giữ nguyên.

Trả lời

8

Phác thảo bài báo đó trở nên sống và sau đó được 'xuất bản'

Điều thông thường sẽ có một tình trạng/loại cờ trên bàn bài viết - IsLive.

Sử dụng các bảng riêng biệt là không cần thiết và không cần thiết; thay đổi các phím nước ngoài cũng không có ý nghĩa gì nhiều. Hãy nghĩ về bài viết như một đối tượng hợp lệ, cho dù bản nháp của nó hay sống. Điểm khác biệt duy nhất là, trong hầu hết các trường hợp bạn chỉ muốn hiển thị các bài viết trực tiếp. Trong một số trường hợp trong tương lai, bạn có thể muốn hiển thị cả hai.

điều mà có thể được chỉnh sửa và có một dự thảo phiên bản mới sau khi ban đầu trở thành sống

Về một bài viết có cả một phiên bản sống và dự thảo - mô hình phổ biến nhất là nên có một bậc thầy Article thực thể/object, và sau đó nói ArticleVersion đến từ đó. Các ArticleVersion sẽ có tài sản IsLive, hoặc thậm chí tốt hơn, các Article chính nó sẽ có một tài sản, CurrentLiveVersionId. Bằng cách đó, có thể có một phiên bản trực tiếp và nháp nằm xung quanh, nhưng bạn chỉ thường tham gia Article vào số ArticleVersion theo số CurrentLiveVersionId đó để tải phiên bản hiện tại.

Ưu điểm của việc có bảng ArticleVersion bao gồm thực tế là toàn bộ lịch sử của bài viết, danh sách thay đổi, có thể được lưu trữ để bạn có thể hoàn nguyên về các phiên bản trước nếu cần hoặc xem lại các thay đổi. Tất cả chi phí thực hiện rất thấp ..

Hãy cho tôi biết nếu tôi có thể làm rõ phương pháp này.

+0

+1, "một bảng bài viết, với bảng nội dung riêng biệt" thực sự là cách để bay tại đây. –

+0

Có khả năng rất dễ dàng - mỗi ArticleVersion sẽ có một ApprovedBy/ApprovedDate, nó không thể được đặt thành phiên bản hiện tại nếu đó là null (trong logic nghiệp vụ)? –

+0

Thay vì có một số phiên bản sẽ không tốt hơn để làm một ngày sửa đổi và ngày tạo cho hàng phiên bản? Bằng cách đó, người dùng có thể sửa đổi bản nháp cho đến khi mặt trời lặn và nó chỉ hiển thị một phiên bản khác khi trang được xuất bản? –

1

Thiết kế của bạn có vẻ phù hợp với tôi. Khi một phiên bản mới có hiệu lực, tôi sẽ:

  1. UPDATE phím PublicContent để trỏ đến các (trước đây) dự thảo bài viết.

  2. DELETE bài viết được xuất bản trước đây không còn được tham chiếu.

  3. NULL phím DraftContent hoặc, nếu mô hình của bạn đòi hỏi phải luôn có một phiên bản dự thảo, INSERT mới, trống dự thảo vào ArticleContent và chỉ phím DraftContent với nó.

Các vấn đề liên quan