Двухэтапное редактирование данных в базе данных - PullRequest
Новая
       24

Двухэтапное редактирование данных в базе данных

1 голос
/ 11 февраля 2011

Для цели вопроса давайте представим, что у меня есть приложение для ведения блога, которое состоит из блогов и подзаписей блога, связанных с блогом.Мои данные хранятся в базе данных в двух отдельных таблицах: Blog и BlobSubEntries, и у меня есть внешний ключ в BlogSubEntries на Blog.Обе эти таблицы содержат данные, которые можно редактировать.

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

Вот несколько вещей, которые следует учитывать:

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

После этого длинного вступления вот мои вопросы:

  • Как бы вы справились с этими двумя шагамиподготовка данных (учитывая тот факт, что есть две модели, связанные друг с другом)?
  • Что, если я хочу развить этот процесс подготовки к управлению версиями?
  • Я недавно читал некоторые на CouchDB,база данных документов упростит такую ​​проблему?Если да, то как?

Спасибо за ваше время.

1 Ответ

1 голос
/ 11 февраля 2011

Быстрый ответ будет иметь такую ​​модель: 

[Blog]<-----[BlogSubEntries]<----[SubEntryDraft]
   ^        (current content)    |-------------|
   |                             |draft_content|
   |                             |-------------|
[BlogDraft]
(draft content)

Если вы хотите заняться версионированием, у вас будет что-то вроде: 

[entry]-(1)-------(N)-[entry_version]
                      |-------------|
                      | version_num |
                      | content     |
                      |-------------|

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

Теперь, когда я думаю об этом, вы также можете сделать это в одной таблице: 

[  BlogSubEntry  ]
|----------------|
| content        |
| entry_id       | <--| composite alternate key:
| version_num    |    | UNIQUE(entry_id, version_num) NOT NULL
| surrogate_key  | <-- PRIMARY KEY
|----------------|
...