Дизайн базы данных для текстовых ревизий

Question

В этом вопросе содержится отличный обзор того, как спроектировать схему истории / пересмотра базы данных для данных, таких как числа или поля с несколькими вариантами выбора.

Однако, нет большого обсуждения больших текстовых полей, как это часто встречается в системах типов блогов / Q & A / wiki / document.

Итак, что считается хорошей практикой для хранения истории текстового поля в системе редактирования на основе базы данных? Хранение в базе данных - даже хорошая идея?

Answer 1

Я разрабатываю вики-движок, а изменения страниц / статей хранятся в таблице базы данных. Каждая ревизия имеет последовательный номер ревизии, в то время как «текущая» ревизия помечается -1 (только во избежание NULL).

Текст ревизии сохраняется как есть, а не в формате Diff или что-то в этом роде.

Я думаю, что производительность не является проблемой, потому что вы вряд ли получите доступ к старым ревизиям очень часто.

Answer 2

Учитывая текущее состояние HDD, просто не стоит усилий по оптимизации механизмов хранения text : таблицы Document (ID, Name) и DocumentRevision (ID, DocumentID, Contents) справятся с этой задачей. ID в DocumentRevision также может служить номером ревизии для всего хранилища. Если это не то поведение, которое вам нужно, назначьте отдельный VersionID для каждой редакции документа.

Answer 3

Часто наиболее разумным способом отслеживания версий документа является отслеживание изменений, внесенных в него. Затем, если запрашивается конкретная версия, ее можно восстановить из текущего документа и частичного набора изменений.

Таким образом, если у вас есть хороший метод описания типов изменений в документе (это будет в значительной степени зависеть от того, что это за документ и как он используется), то непременно используйте базу данных для отслеживания изменений и, следовательно, версий.