Cách để phiên bản tài liệu do người dùng tạo

8

Tôi có một tài liệu trực tuyến về cơ bản được lưu trữ vào cơ sở dữ liệu dưới dạng chuỗi XML.

Tôi đang nghĩ về một cách để thực hiện phiên bản tài liệu cho người dùng. Để người dùng có thể quay lại các phiên bản trước của tài liệu.

cập nhật Trong trường hợp của tôi, đó là một ứng dụng web với hàng trăm ngàn người dùng. Một người dùng có thể lưu trữ số lượng tài liệu không giới hạn. XML cho tài liệu được lưu trữ trong trường blob MySQL vì vậy nó không nhỏ. Cuối cùng, tôi cần phải giới hạn bằng cách nào đó nhưng đó là một chủ đề khác nhau.

Có một cách tiêu chuẩn để tiếp cận điều này? Tôi chỉ nên lưu trữ sự khác biệt giữa các phiên bản? Những thứ khác mà tôi cần xem xét là gì?

design architecture versioning

— nhà phát triển
nguồn

1

Câu hỏi thú vị ở đây là: bạn có cơ sở hạ tầng MYSQL DB hiện tại nơi dữ liệu phải được tích hợp (đặc biệt là một hệ thống được chia tỷ lệ cho nhiều người dùng đó) không? Gợi ý RCS của Crazy Eddie dường như không dễ dàng được tích hợp trong một hệ thống như vậy.

— Doc Brown

Mô hình bảo mật là gì - Tôi cho rằng tài liệu của mỗi người dùng là riêng tư?

— Michael

@Michael Có mỗi tài liệu người dùng là riêng tư

— dev.e.loper

@DocBrown Có Tôi có một bảng db Mysql hiện có nơi các tài liệu xml này được lưu trữ ngay bây giờ.

— dev.e.loper

@ dev.e.loper: Tôi đoán quyền riêng tư không được thi hành bởi máy chủ DB, phải không? Số lượng người dùng bạn đề cập cho thấy bạn đang nói về một giải pháp máy chủ web được chia tỷ lệ. Câu hỏi được đặt ra ở đây là: bạn có muốn / phải giữ dữ liệu XML trong cơ sở dữ liệu hay bạn có thể tự do chọn một công nghệ khác cho phần dữ liệu đó không?

— Doc Brown

13

Tại sao không sử dụng kho lưu trữ kiểm soát nguồn? Nó sẽ chiếm ít không gian lưu trữ hơn, thực hiện mọi thứ bạn hiện muốn và sẽ dễ dàng cho phép bạn mở rộng khái niệm hơn nữa thành các nhánh, thẻ, v.v ... tất cả những thứ bạn nhận được từ một RCS. Tại sao phải phát minh lại bánh xe?

— Edward lạ
nguồn

Chính xác thì bạn có ý nghĩa như thế nào? Bạn đang nói cài đặt SVN trên máy chủ của tôi và sử dụng api để lưu trữ các tệp đó?

— dev.e.loper

Có một cổ chai ở đâu đó trong phương pháp này? Ví dụ: nếu tôi có 50.000 người dùng lưu / phiên bản công việc của họ. Kho lưu trữ kiểm soát nguồn cần xử lý phiên bản cho 50.000 chính xác?

— dev.e.loper

OP đang nói về một cơ sở dữ liệu (tôi đoán, một cơ sở dữ liệu hiện có). Tôi không biết bất kỳ hệ thống kiểm soát nguồn nào dễ dàng tích hợp vào một lược đồ cơ sở dữ liệu hiện có.

— Doc Brown

@ dev.e.loper - bao gồm một RCS phong nha, bao gồm SVN, có thể xử lý nhiều người dùng đó.

— Edward Strange

5

Vì bạn đang làm điều này trong cơ sở dữ liệu, cách dễ nhất để phiên bản chuỗi XML của bạn sẽ là tạo một bảng Lịch sử mới với các cột sau:

ID lịch sử
Chuỗi XML mới (cột tùy chọn)
Chuỗi XML cũ
Chèn dấu thời gian

Chèn một hàng vào bảng Lịch sử này trước khi bạn cập nhật hàng trên bảng chuỗi XML.

— Gilbert Le Blanc
nguồn

Nếu bạn cập nhật hàng trong bảng chuỗi XML, không có cách nào để đưa phiên bản trước ra ngoài. Tất cả những gì bạn có thể làm là xem lịch sử ngày thay đổi. Bạn cần thực hiện chèn thay vì cập nhật ... tốt nhất là tìm khác biệt.

— Edward Strange

@CrazyEddie: Phiên bản trước (phiên bản cũ) nằm trong bảng Lịch sử. Diffs không cần thiết cho một tài liệu.

— Gilbert Le Blanc

"Không cần thiết" - bạn không biết tài liệu này lớn như thế nào, tần suất thay đổi và nếu OP có thể không có nghĩa là "một tài liệu cho mỗi người dùng". Vì vậy, "không có khác biệt cần thiết" chỉ là một phỏng đoán hoang dã. Tuy nhiên tôi đã cho bạn +1, vì tôi nghĩ câu trả lời của bạn chỉ đúng hướng. Nhưng bạn có thể cải thiện nó bằng cách giải thích rõ hơn những cột "phiên bản mới" và "phiên bản cũ" sẽ chứa những gì (chuỗi XML, tham chiếu đến ID lịch sử trước đó hoặc một cái gì khác?)

— Doc Brown

@Doc Brown: Và bạn không biết tần suất phiên bản cũ của chuỗi XML được yêu cầu, chưa kể đến thời gian và nỗ lực để viết một công cụ tìm khác biệt, cũng phải mở ra. Bạn thậm chí không biết liệu cơ sở dữ liệu có nén chuỗi văn bản hay không. Tôi đã sửa các tham chiếu cột.

— Gilbert Le Blanc

@GilbertLeBlanc: Cả hai chúng tôi đều không biết điều đó (khi OP viết phiên bản đầu tiên của câu hỏi) - và vì thế tôi sẽ không viết "diffs là cần thiết" hoặc "diffs không cần thiết" ở đây. Tôi chỉ đề nghị không bắt đầu với một giải pháp khác phức tạp hơn nếu một giải pháp không khác biệt đơn giản hơn có thể là đủ. Tôi đoán đó là những gì bạn có ý nghĩa.

— Doc Brown

3

Có một cách tiêu chuẩn để tiếp cận điều này?

Đối với cách tiếp cận dựa trên tiêu chuẩn, hãy xem phần mở rộng Delta-V cho WebDAV (bản thân nó là một phần mở rộng được hỗ trợ rộng rãi cho HTTP). Delta-V bổ sung phiên bản cho WebDAV và được mô tả trong RFC 3253 .

— Caleb
nguồn

1

Một cách tương đối đơn giản là tăng id sửa đổi sau mỗi lần lưu và lưu tài liệu xml mới theo id sửa đổi mới đó.

bảng: tài liệu

doc_id | name          | current_revision
   1   | Shopping List |       5

bảng: doc_Vvutions

doc_id | revision | timestamp | xml_blob
  1    |    1     | 2012...   |
  1    |    2     | 2012...   |
  1    |    3     | 2012...   |
  1    |    4     | 2012...   |
  1    |    5     | 2012...   |

Bạn cũng có thể xem xét việc lưu trữ các tệp xml riêng trong hệ thống tệp. Bạn có thể thay đổi bảng doc numvutions bằng URL / đường dẫn đến tệp chứ không phải là blob. Điều đó sẽ cho phép db của bạn xử lý khối lượng cao hơn nhiều trên một máy chủ vì cơ sở dữ liệu sẽ không lớn bằng (bạn có thể di chuyển các tài liệu sang một máy chủ khác) và bạn sẽ lấy tải tài liệu ra khỏi máy chủ db.

Cá nhân, tôi sẽ không lưu trữ sự khác biệt tập tin. Thay vào đó, tôi sẽ lưu trữ bản sửa đổi hoàn toàn mới của tệp mỗi lần. Lưu trữ là giá rẻ, và không cần phải phức tạp hóa mọi thứ. Chức năng 'diff' có thể được thực hiện sau này nếu cuối cùng hóa ra bạn thực sự cần nó. Nếu bạn lưu trữ diffs, hãy lưu ý rằng nó có thể giới thiệu một loạt các phức tạp bất ngờ, ví dụ nếu bạn cần tìm kiếm văn bản của các tài liệu.

— Chưởng môn
nguồn

Về việc lưu trữ sự khác biệt của tệp, tôi đang tìm cách lưu trữ các khác biệt với sự trợ giúp của thư viện patch-match-patch code.google.com/p/google-diff-match-patch

— dev.e.loper

1

Tại sao không bắt chước một bản ghi cơ sở dữ liệu?

Về cơ bản, các thay đổi được đánh dấu theo thứ tự thời gian là giao dịch. Đối với DB tài liệu, một giao dịch sẽ bao gồm dấu thời gian khác nhau blob + thay vì mục hàng của bảng nhưng khái niệm này hoạt động như nhau. Khá nhiều cách tương tự như hệ thống kiểm soát phiên bản làm việc.

Để giữ mọi thứ linh hoạt, hãy giữ một bản sao được lưu trong bộ nhớ cache của phiên bản hiện tại. Nếu ai đó cần quay ngược thời gian, họ có thể khôi phục (tức là đảo ngược) các giao dịch cho đến khi đạt được yêu cầu lịch sử mà họ cần. Ý tưởng là bản sao được lưu trong bộ nhớ cache không thay đổi cho đến khi thao tác lưu được thực hiện.

Để duy trì tính nhất quán, bạn cũng cần tính đến các lần khôi phục tài khoản. Theo những gì tôi đã mô tả, giả sử người dùng quay lại 5 phiên bản. 5 giao dịch sẽ được áp dụng ngược theo thứ tự thời gian đảo ngược cho phiên bản hiện tại nhưng khi trạng thái đó được lưu, giao dịch được lưu trữ dưới dạng khác với trạng thái đó so với phiên bản hiện tại.

Về cơ bản, lịch sử không bao giờ được viết lại, chỉ được sử dụng lại để tạo các phiên bản mới.

— Evan Plaice
nguồn