2011-12-15 29 views
7

Tôi muốn lưu trữ một bài đăng trên blog trong cơ sở dữ liệu. Tôi nghĩ sẽ tốt hơn nếu có các phiên bản khác nhau của dữ liệu đó, giống như việc kiểm soát phiên bản dành cho các tệp văn bản.Các cách tiêu chuẩn/được khuyến nghị để lưu trữ dữ liệu cơ sở dữ liệu được kiểm soát phiên bản là gì?

Vì vậy, tôi tưởng tượng nó hoạt động như một hàng trong một bảng, có điều khiển phiên bản. Vì vậy, ví dụ: bạn có thể truy xuất phiên bản mới nhất của hàng đó hoặc phiên bản trước đó. Bạn thậm chí có thể chi nhánh từ hàng đó.

Có điều gì như thế này tồn tại không?

Thông tin hữu ích: Tôi hiện đang sử dụng Python, Django & MySQL. Tôi đang thử nghiệm với MongoDB

Chỉnh sửa cho bối cảnh rõ ràng/hơn: Tôi đang tìm một giải pháp phù hợp hơn với "kiểm soát phiên bản" của các hàng so với cơ sở dữ liệu; Tôi không quan tâm nhiều đến việc phân nhánh toàn bộ cơ sở dữ liệu. Ví dụ: tôi có thể truy vấn nội dung của bài đăng trên blog vào ngày 1/1/2011 và tại ngày 1/1/2010 (không chuyển đổi cơ sở dữ liệu).

+0

Bạn đã cân nhắc sử dụng hệ thống kiểm soát phiên bản như git chưa? Sẽ là thú vị để xem ưu và nhược điểm của giải pháp như vậy. – milan

+0

@milan - vì khi nào cơ sở dữ liệu phiên bản git ** ghi **? –

+0

Câu hỏi không nói * bất kỳ bản ghi cơ sở dữ liệu nào, nó nói các bài đăng blog, chủ yếu là văn bản, vậy tại sao không? – milan

Trả lời

2

Trước hết, tôi phải nói đây là một câu hỏi thú vị.

Trong dòng công việc của mình, tôi đã lưu các phiên bản của nhiều mục nhập người dùng khác nhau. Cách tôi làm điều đó, và bằng mọi cách tôi không thực sự biết nếu đó là đúng cách hay không, là như sau:

Tôi có một bảng masterrevisions bảng. Tôi đã chọn 2 tên này chỉ vì mục đích của ví dụ.

gì thầy làm là lưu trữ các thông tin sau:

  • id (autoincrement)
  • version_id (int)

revisions cửa hàng như sau:

  • id
  • master_id
  • version_id
  • phần còn lại của dữ liệu có liên quan về đối tượng tham gia (ngày tháng, vv)

Những gì tôi đạt được theo cách này là tôi đã nhận được một ID của, chúng ta hãy nói một bài đăng blog. Nếu ai đó chỉnh sửa bài đăng, tôi sẽ lưu trữ thông tin đó vào bảng revisions. Qua trình kích hoạt, tôi đang tăng số version_id trong bảng revisions. Sau đó tôi cập nhật bảng master với số mới nhất version_id. Bằng cách đó tôi không phải thực hiện MAX() khi tôi muốn xem phiên bản mới nhất là gì.

Bằng cách đó tôi đã có được hệ thống phiên bản đơn giản nhưng mạnh mẽ của nội dung trang web. Thật dễ dàng để xem các thay đổi và cũng rất nhanh để lấy dữ liệu nếu bạn lạm dụng một số tính năng mát mẻ của MySQL (trong các bảng thực tế của tôi), tôi đang lạm dụng khóa chính được nhóm của InnoDB ở mức tối đa. Tôi đã đăng ở đây).

3

Kiểm soát phiên bản là một chủ đề phức tạp; thực hiện đúng là thực sự khó khăn, đó chính là lý do tại sao ngay cả sử dụng ví dụ: git có thể khó khăn. Tôi không muốn viết một hệ thống điều khiển phiên bản đầy đủ.

Đối với yêu cầu đơn giản hơn, hãy xem xét cấu trúc này, trong pseudo-MongoDB/JSON:

BlogPost { 
    "_id": ObjectId("..."), 
    "slug" : "how-to-version-my-posts", 
    "author" : "cammil", 
    "published" : date, 
    "lastModified" : date, 
    "publicVersion" : 32, 
    "draftVersion" : 34, 
    "teaserText" : "lorem ipsum dolor sit amet..." 
} 

BlogPostBody { 
    "_id" : ObjectId("..."), 
    "Version" : 32, 
    "Text" : "lorem ipsum dolor sit amet..." 
} 

Vì vậy, ý tưởng ở đây là để lưu trữ từng phiên bản riêng biệt và một con trỏ lên phiên bản nào hiện tại và phiên bản hiện tại cho các biên tập viên , blogger, v.v.

Câu trả lời của tôi là một trung tâm MongoDB nhỏ (vì tôi đã xây dựng một công cụ blog dựa trên MongoDB để sử dụng tại nhà), nhưng nó cũng hoạt động tương tự với bất kỳ hệ thống lưu trữ nào.

Ưu điểm:

  • Không cần phải làm MAX thắc mắc của số phiên bản cho một trong hai bài viết công cộng hay tư nhân
  • Không tương quan last edited đến các số phiên bản, mà có thể không được mong muốn
  • phép versioning thậm chí nếu một phiên bản nhất định đã được xuất bản
  • Có thể tìm nạp quảng cáo xem trước video phải tìm nạp toàn bộ bài viết

Nhược điểm:

  • Sao chép toàn bộ văn bản mỗi lần. Không phải là một mối quan tâm thực sự cho dữ liệu văn bản tôi đoán (cố gắng gõ 1GB ...). Tuy nhiên, sẽ là một vấn đề đối với các trang web viết blog lớn hơn. Giảm thiểu: Nén văn bản bằng cách sử dụng deflate, delta-compression.
  • nhu cầu để cập nhật hai đối tượng trên bản cập nhật
2

OffScale DataGrove cho phép bạn phiên bản bạn toàn bộ DB.

Nó theo dõi tất cả các thay đổi xảy ra với DB và bạn có thể gắn thẻ các phiên bản và chuyển đổi qua lại giữa chúng. DataGrove là duy nhất trong thực tế là nó phiên bản toàn bộ DB-schema và dữ liệu.

Trong ví dụ của bạn - chỉ cần thêm hàng/dữ liệu bạn muốn vào DB và gắn thẻ phiên bản. Bạn sẽ luôn có thể quay lại phiên bản đó và thậm chí là chi nhánh từ nó.

+1

Từ mô tả của bạn, DataGrove dường như được định hướng nhiều hơn đối với phân nhánh cho toàn bộ cơ sở dữ liệu so với các hàng riêng lẻ. (Xem chỉnh sửa) – cammil

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