Bagaimana cara menyimpan riwayat edit bidang string besar dalam basis data relasional

Solusi yang saya kerjakan saat ini, yang sejauh ini berfungsi dengan baik, mengimplementasikan desain yang saya usulkan dalam pertanyaan

Saya akan membagikan spesifikasi penerapan saya di sini

Untuk membuat delta dan menggunakan untuk merekonstruksi teks lengkap, saya menggunakan perpustakaan google-diff-match-patch . Anda dapat membaca dokumentasi API agnostik implementasi untuk lebih memahami contoh kode di bawah ini, meskipun cukup mudah dibaca.

google-diff-match-patch memiliki implementasi Java dan JS sehingga saya dapat menggunakannya untuk menghitung delta dengan Java di server. Saya memilih untuk mengonversi setiap delta menjadi String keduanya sehingga dapat dengan mudah disimpan dalam database, dan mudah dikonsumsi oleh perpustakaan JS di klien. Selengkapnya di bawah ini.

public String getBackwardsDelta(String editedBlogPost, String existingBlogPost) {
    diff_match_patch dmp = new diff_match_patch();
    LinkedList<diff_match_patch.Patch> patches = 
        dmp.patch_make(editedBlogPost, existingBlogPost);
    return dmp.patch_toText(patches);
}

N.B. sesuatu yang butuh beberapa saat untuk saya pahami adalah bagaimana cara menurunkan build resmi google-diff-match-patch menggunakan pakar. Itu tidak ada di repo pusat pakar, tetapi di repo mereka sendiri di googlecode.com. Sebagai catatan, beberapa orang telah melakukan fork dan meletakkan versi fork mereka di maven central, tetapi jika Anda benar-benar menginginkan versi resmi, Anda dapat memperolehnya dengan menambahkan repo dan dependensi di pom.xml Anda sebagai berikut

<repository>
  <id>google-diff-patch-match</id>
  <name>google-diff-patch-match</name>
  <url>https://google-diff-match-patch.googlecode.com/svn/trunk/maven/</url>
</repository>

<dependency>
  <groupId>diff_match_patch</groupId>
  <artifactId>diff_match_patch</artifactId>
  <version>current</version>
</dependency>

Untuk bagian depan, saya melewati teks lengkap posting blog terbaru, bersama dengan rantai delta mundur dalam waktu yang mewakili setiap pengeditan, dan kemudian merekonstruksi teks lengkap setiap versi di browser di JS.

Untuk mendapatkan perpustakaan, saya menggunakan npm + browserify. Library tersedia di npm sebagai diff-match-patch . Versi 1.0.0 adalah satu-satunya versi.

getTextFromDelta: function(originalText, delta) {
  var DMP = require('diff-match-patch'); // get the constructor function
  var dmp = new DMP();
  var patches = dmp.patch_fromText(delta);
  return dmp.patch_apply(patches, originalText)[0];
}

Dan hanya itu, ia bekerja dengan luar biasa.

Dalam hal menyimpan hasil editan postingan blog, saya hanya menggunakan tabel BLOG_POST_EDITS tempat saya menyimpan id posting blog, stempel waktu saat pengeditan dilakukan (yang kemudian saya gunakan untuk memesan pengeditan dengan benar untuk membuat rantai saat merekonstruksi versi teks lengkap pada klien), dan delta mundur antara siaran langsung saat ini entri blog di BLOG_POST tabel, dan versi entri blog yang telah diedit.

Saya memilih untuk menyimpan 'rantai' delta karena cocok dengan kasus penggunaan saya, dan lebih sederhana di ujung kode server. Itu berarti untuk merekonstruksi versi M dari N, saya harus mengirim klien rantai delta N-(M-1) kembali dari teks lengkap posting blog langsung ke versi M. Tetapi dalam kasus penggunaan saya, saya kebetulan ingin mengirim seluruh rantai setiap kali, jadi tidak apa-apa.

Untuk efisiensi over-the-wire yang sedikit lebih baik untuk meminta versi tertentu, semua delta dapat dihitung ulang dari versi posting blog yang baru diedit kembali ke setiap versi (dipulihkan) setiap kali pengeditan dilakukan, tetapi ini berarti lebih banyak pekerjaan dan kompleksitas pada server.